Hi, > Would such a course seek to teach the principles or the rules?
It’s currently an hour long, and while I do/would explain why some things are done that way, it’s not a deep dive into the underlying principles as I don’t think there enough time to do that. I think it’s easier to know policy and then understand why it that way and how the preinicaples apply, rather than the other way about, but I could be mistaken. You're welcome to review it and give feedback on it which I’ll take into consideration and apply. I use the Apache Wombat material I made some time ago, a real release of an incubating project Pony Mail, and review a real (unnamed) TLP project LICENSE and NOTICE file and give some simple scenarios/candidates for committership and have an open discussion of if people should be committers. They are no correct answers to if the release should be released (but it probably should be), the LICENSE and NOTICE are OK (they have a few issues), or if the committers should be voted in ( it would depend on the PMC in question), that is all up to the participants. > I ask because your original proposal says " making and voting on releases and > voting on committers into the projects". There are no ***rules*** about > having to vote. There are principles about how to build and recognize > consensus. But, despite what much of the incubator documentation says, there > are no formal rules about it. If you look at the incubator policy [1] you’ll note it uses MUST and SHALL quite carefully (as per [2]), no where does it say releases MUST be voted on so yes I’m aware a formal vote is not required. However I’m only aware of one TLP project that doesn’t vote on committers/releases in the way that most projects do (Apache SVN) and vaguely remember them making major changes on how releases were made at some point after one didn’t go so well. The exact detail of those differences I’m unaware of. I can’t recall a single incubator project in the last 5 years that hasn’t voted on releases. Anyone know of other examples where projects don’t vote on releases or committers? Is so please share them. > I'm 100% for teaching people the principles of consensus building around > releases and honoring people with committership. Even better if such a course > gave concrete examples of how different communities apply those principles in > different ways. If anyone (including you) can give me examples then I’ll certainly use them. The projects I’m involved in (or have been involved in) are certainly quite different to each other but I can't think of any major ways (with the exception of the Incubator) that they apply the principles in different ways. Some have set different bars for committership and some more welcoming than others but that’s not really a big difference in that regard. > However, I'm 100% against an opinionated piece that gives the impression that > there is only one way to do things here in Apache. We already have way too > much of that in Incubator docs. Patches are welcome. Thanks, Justin 1. https://incubator.apache.org/policy/incubation.html 2. https://www.ietf.org/rfc/rfc2119.txt --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
