openownership
Improve governance practices
I feel disappointed and frustrated that, after contributing significant time and effort to suggesting improvements or alternatives to proposals, that these contributions do not see any substantive direct response, and that instead the standard development team "accepts" (as in, decides to implement) its own original proposal, with very little (or no) effort toward engaging in discussion. (#475, #477, #482)
The purpose of discussion is for participants to weigh the advantages and disadvantages of alternatives and work toward "broad consensus", which is a key principle of any open standard, expressed in https://open-stand.org and elsewhere. This doesn't mean that everyone agrees, but at minimum that everyone feels heard and can fully understand the reasons for a decision, and the relative priority given to different advantages/disadvantages.
Without broad consensus, BODS is not an open standard – more an idea pushed by OpenOwnership, with "Standard" in its name.
The motivation for my contributions is that the current direction of BODS is one that I cannot recommend to any government or other potential publisher that I work with.
As a user of this type of data, I would prefer the publisher to use their own bespoke format, rather than BODS. This wouldn't have the benefit of standardization (e.g. being able to reuse code or methodologies across publishers), but it would have at least the benefit of representing more-or-less directly the publisher's data sources, without passing through the convolutions of BODS.
From a publisher's perspective, a major benefit of a standard is that it saves them the time to design their own format. However, the complexity of BODS is such that it is likely less time-consuming to invent a "good enough" format rather than figure out how to transform their data to BODS.
I contributed so that there would be a possibility that I could recommend BODS.
Through this experience, I've now learned that BODS does not apply many common principles of standard development, and so I cannot recommend it for a second reason: it is not really an open standard, with proper governance.
Hi @jpmckinney,
Thanks for noting your concerns, some of which I have previously replied to and some of which we also discussed when you, me and @kd-ods spoke recently on a call.
As I said on that call, Open Ownership and Open Data Services are in the process of updating the governance processes for BODS as we continue to work on the standard and move towards a version 1.0.
Some clear commitments in this area have been made by our team during the evaluation of BODS by the UK Open Standards Board in 2021 ahead of it going on to be approved for use by the UK government.
Work towards the introduction of these processes is ongoing but not complete by any means.
On being heard, our team has responded to each of your comments to engage with the issues and committed to revisiting a number of them in later standard development plans (see details below).
In terms of your comment about rename subject in ownership-or-control statements to entity, @kd-ods agreed in her comment below that this is something we can come back to ahead of a version 1.0 of BODS - but it is not something we have planned in for version 0.4. I have logged this internally to come back to as we plan work beyond version 0.4.
On requiring statementDate in future versions of BODS - as per your feedback here - Kadie has responded with a commitment that we "will do a wholesale review of required fields before a version 1 release".
I hope we can continue to actively engage on these topics and I assure you that we value these contributions and discussions.
Hi Stephen, the current discussions don't meet my expectations for standard development, from my experience as an invited expert to the W3C Government Linked Data Working Group, as a co-author of the W3C vCard Ontology, as a contributor to the DCAT-US Schema, and as an editor of OCDS, OC4IDS and Popolo.
Being heard means more than being acknowledged. To illustrate via exaggeration, the present discussions are a bit like "OO: We'll order hamburgers", "JM: I'm concerned about potential vegetarian guests, livestock's climate impact, etc." "OO: Interesting." Then a few weeks later, "Thank you everyone for your diligent contributions. After careful consideration, we'll order hamburgers."
My experience at the W3C is that it takes a lot more to achieve the following:
- Demonstrate that a contribution has been understood, considered and taken into account.
- Make the contributor feel valued and rewarded for having contributed, thereby encouraging continued engagement.
- Build common agreement (or, at minimum, understanding) for any decisions taken.
Some practical steps that can be taken are:
-
Inform everyone equally, prior to a decision. This is common to standard development as well as other fields, like the principle of "free, prior and informed consent" in Indigenous relations.
- In the recent updates sharing internal decisions, some doubts or objections to others' contributions are expressed for the first time as part of the decision. This prevents contributors from addressing the doubt or objection, or from clarifying any point they feel was misunderstood. The above goals can't be met in these circumstances.
-
Express a scope for decisions. Contributors need to know what is in/out of scope for the next version. This avoids a feeling of wasted time, if a contribution is deemed to be out of scope during the discussion.
- As far as I can tell, decisions about naming – including new fields – is out-of-scope for 0.4 (this is very unusual).
-
Express a timeline for decisions. The timeline can be a rough schedule, e.g. "once the release candidate is published, there will be one month for comments, followed by ...." This helps contributors plan their time.
- I'm not aware of BODS having any public timeline.
-
Give sufficient notice prior to decisions. If an issue needs to reach a decision shortly, update it with a notice. (Though, if the issue hadn't yet reached broad consensus, an absence of engagement does not imply consensus.)
- So far, decisions are made without any notice of an upcoming decision.
-
Respond substantively to all points, and check in whether the responses are satisfactory. if a point receives a cursory response ("Interesting idea") or no response, then the above goals can't be met. If an editor wants to proceed to a decision, but voiced disagreement with a contributor, it is the editor's responsibility to check in – it is not up to the contributor to divine that a decision is imminent, and to write back.
- I've had more substantive discussions with other contributors than with the standard development team.
-
Incorporate future work in decisions. If a contribution can't be acted on, or if a decision needs to be made without addressing all concerns, express the plans for returning to those items in the decision. That said, the issue that was raised but postponed shouldn't be entirely contradictory to the decision. It needs to be coherent with the decision.
- The recent updates don't mention any such plans. In some cases, my contributions are contrary to the decision – such that the future work could involve the decision's reversal, which is a bit odd as standards go. In OCDS, a simple step we can often take is to open a new issue and link to it from the discussion, when closing an issue.
Lastly, in terms of due process in standard development, if broad consensus can't be reached, the decision should be postponed.
Hope this helps.
FWIW, I don't think GitHub Discussions have a good UI, which is why OCP only uses GitHub Issues. GitHub Discussions encourages multiple threads (instead of a single thread), which makes it harder for both contributors and editors to follow. A single thread is more appropriate when the goal is consensus, because it keeps everyone in the same conversation, and better controls for proposals diverging in multiple directions. GitHub Discussions makes it harder to re-summarize the conversation in light of recent contributions (in GitHub Issues, this can be done periodically via the most recent update, which is always at the bottom).
@jpmckinney, I really do regret that you've been left disappointed and frustrated. I can see that your expectations go beyond what we currently offer in terms of clarity around governance practices. As Stephen says: this is something that we are working on. Your enumeration of practical steps is very helpful - thank you. Watch this space.
I have very much valued your input on the substantive elements of the data standard. As you've identified with the hamburger-ethics analogy: the challenge with these proposals was that a decision about prioritising the addressing of certain features had already been made. Questioning that prioritisation was not in scope for consideration. Which raises the important question: how can priorities for BODS's development be influenced by the community of data publishers and users in a timely manner? We need a clear answer to that question (which takes us back to the need for governance improvements). One part of the answer, though, is that we have transparency about which high-level features need addressing, in the form of the feature-tracker (documentation here).
On one substantive issue, you, I and others have all come to a similar viewpoint: the over-complexity of BODS. As you say:
From a publisher's perspective, a major benefit of a standard is that it saves them the time to design their own format. However, the complexity of BODS is such that it is likely less time-consuming to invent a "good enough" format rather than figure out how to transform their data to BODS.
I will be adding to the feature tracker a new ticket which speaks to the desire to simplify BODS to make it more usable. This will mean that it can be prioritised for future work (via a transparent process)! When you are ready to re-engage with the work on BODS, I would welcome your input to that ticket and future discussions on development priorities.
As part of ongoing work to release version 0.4 of BODS, we will be updating the Governance page in the documentation - see https://github.com/openownership/data-standard/issues/563 - to take comments here onboard as well as to more clearly set out some of the current feature development processes for BODS as set out in the BODS development handbook.
Beyond the release of version 0.4, the teams at Open Ownership and Open Data Services will be working to improve and enhance the governance process for BODS.