search

okfn / opendefinition

Open Definition source
https://opendefinition.org/
Creative Commons Attribution 4.0 International
109 stars 123 forks source link

Open Definition versioning: cleaner approval process, overall revisions #130

Open wolftune opened 9 years ago

wolftune commented 9 years ago

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.

wolftune commented 9 years ago

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.

wolftune commented 9 years ago

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:

  1. work on known issues
  2. all issues addressed internally, we vote on RC already
  3. then announce widely
  4. if only typo fixes come in, accept them and we're done, vote on final; if other things besides typos come up, we're back to step 1 and work on what will be the next number RC.

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.

Hayzlee11 commented 3 months ago

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.

wolftune commented 3 months ago

get to release candidates, do them OFTEN, quickly, once known issues are done, and then don't push them through so hard.

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.

hlainchb commented 3 months ago

i cant believe this has been going on all this time

That's not what happens. That's an incorrect paraphrasing of what happens. There is only one vote by the council.