Open Definition versioning: cleaner approval process, overall revisions #130
Conversation
It makes no sense for a "release candidate" phase to have all of: a delay before a vote, and a vote, and an announcement, and a wait period, and another vote. The summary of the text from my update is: * consensus seems apparent (no issues outstanding) * do immediate vote on release candidate (no delay, no extra announcements) * announce the release candidate, have delay, accept typo fixes, *readily* move back to earlier stages to create newer release candidate if issues come up * when through this without issues, then final vote Basically, there's no reason to be so hesitant to get to release candidates, do them OFTEN, quickly, once known issues are done, and then don't push them through so hard.
|
To be clear, I feel the current proposal and the current process was really out of balance in making it so the idea of a "release candidate" was a big deal, like major concerns were needed to undo it, and voting to accept something as a "release candidate" was basically like saying it was final unless there was a real veto. I think that isn't the point. The point of a "release candidate" is that we don't know already that it's problematic, so it might be the final release, but it's perfectly fine to make it a candidate and then have a period for feedback to determine if we step back and develop a newer RC. Every time the committee basically says "all the issues we know about have been addressed" we should basically have a release candidate. Then, we have a period to get feedback on it, and we don't push hard on the NO CHANGES emphasis, we just say that if there are only typo changes, the process continues to finality, and if there are other proposals, then we're back to discussion to work toward an updated RC2 or RC3 or RC7 or whatever. Get to RC's faster, let it be normal to revise them to new RC versions. Once an RC goes without objections / updates, then it becomes final. I really feel the old process felt like the first time we consider an RC, it's already too late for updates except if something is serious enough for a veto. My suggestions here are much better in many respects. The exact wording could be clarified / updated, but I want this more-RCs-faster approach. |
|
|
||
| 2. A new draft document is started. Chair notifies the list and other relevant fora that a new draft document has been started summarizing the issues that the upcoming release is to address and inviting participation. | ||
|
|
||
| 3. Issues with the current Open Definition are identified. The Open Definition community will discuss on the mailing list and decide which issues are to be dealt with in the next release reach consensus on each of these issues. The draft document is updated to relfect current consensus. |
There was a problem hiding this comment.
Note: this was a totally redundant item to item 1, like it was just a typo when someone moved it and forgot to delete the old lines or something.
|
sorry for the verboseness, trying to be as clear as possible: I think it's fine to have RCs before announcing to the broader community, as long as it's clear that it's perfectly acceptable for people to offer new suggestions at that point, it just means that RC version is not going to be the final and we're now working toward the next RC version. New summary:
This is so much simpler then weird multiple delay strangeness. Sorry my pull request isn't this clear. I think I've made my point now anyway in this thread. |
|
|
||
| 4. The Open Definition Advisory Council chair will summarize the consensus to the Advisory Council on the mailing list and to other relevant fora, okfn-discuss at a minimum. | ||
| 4. When no outstanding issues remain unsettled, the Open Definition Advisory Council chair will summarize the consensus to the Advisory Council on the mailing list and to other relevant fora, okfn-discuss at a minimum. |
There was a problem hiding this comment.
I don't see how "When no outstanding issues remain unsettled" is practical. There are always going to be outstanding issues. I think someone needs to draw the line somewhere and say "this is in" and "everything else is for later", typically related to the intention of the release. I think it's up to the chair to draw that line and then it is up to others to protest before a vote is called if they want to object.
There was a problem hiding this comment.
Okay, well, the intention I have is: When all outstanding concerns about this have been acknowledged and either dealt with or a decision made to put them off to a later time/version.
Split up more steps, clarified many previously confusing items, emphasized the idea of deciding a scope to be addressed for each release.
mlinksva
changed the title
|
| @@ -2,19 +2,26 @@ | |||
| Definition Revision Approval Process _- draft_ | |||
| ==================================== | |||
|
|
|||
| 1. Issues with the current Open Definition are identified. The Open Definition community will disucss on the mailing list and decide which issues are to be dealt with in the next release reach consensus on each of these issues. | |||
There was a problem hiding this comment.
This step just describes the process starts. People discuss issues on the mailing list and agree informally about what needs to happen.
I totally like this point. Getting candidates out for feedback is the key. They only need so much extreme preparation if time and openness to feedback is limited. If RCs are really readily adaptable before real release, then it's safe to propose RCs faster. |
That's not what happens. That's an incorrect paraphrasing of what happens. There is only one vote by the council. |
It makes no sense for a "release candidate" phase to have all of: a delay before a vote, and a vote, and an announcement, and a wait period, and another vote. The summary of the text from my update is:
Basically, there's no reason to be so hesitant to get to release candidates, do them OFTEN, quickly, once known issues are done, and then don't push them through so hard.