Hi Upayavira While reviews are not strictly required by Apache, each community has it's own culture. The decision to pre review or post review is a trade off. With pros and cons on each side. In my opinion we should to continue to pre review each commit for the following reasons:
- Each developer has it's own style, which not necessarily complies with the style of Wave code. IMHO it is very important to keep the style uniform over the whole code base and the standards should be equally high. It is easy to let the code quality slip down, but very hard to bring it back. - Wave code is sometimes complex with many layers of abstractions, which means that's it is easy to break something but hard to fix. - Absence of code reviews can hinder adoption of Wave by big/governmental organizations that want each line of code to be reviewed by community to reduce the risks of malicious code planted into the code base. - Code reviews force open and constructive discussions, which allows to to keep the community consensus over the ways the product develops. On Thu, Jun 20, 2013 at 4:02 AM, Upayavira <u...@odoko.co.uk> wrote: > > > On Wed, Jun 19, 2013, at 03:00 PM, Christian Grobmeier wrote: > > Hi all, > > > > from time to time I see in several projects the term "lead developer" > > coming up. Sometimes incubating projects are confused also when to > > grant committership. > > > > On the "lead developer": the ASF is a do-cracy, as we sometimes say. > > The guy who "does things" is actually leading it. We do not have a > > hierarchy, like a senior programmer who tells juniors what to do. The > > whole project is "leading" the project. There are no real managers or > > something like that. The term "lead" does let "non-leads" wait before > > they are taking action. But in fact, everybody reading this list is > > invited to take initiative and do things. Even non-committers can > > "lead" something. > > > > When a non-committer has show commitment to a project, he gets > > invited. Projects have different bars for inviting people. Personally > > I always prefer to set a pretty low bar for earning committership. > > Becoming a PMC member is a different thing. The bar should be higher. > > For example, I think about a candidate if he is around for lets say 3 > > months and contributes. Contributions can be answering user questions, > > writing docs, cleaning up Jira, writing code and so on. Translators, > > Community people, they all can become committer. > > After three months it is clear if the person wants to stay around or not. > > > > The PMC should then open a [DISCUSS] thread on private and speaking > > about the candidate. He should fit to the team. Toxic people can be > > dangerous. > > > > You are project are free to choose when it is time to invite a person. > > > > In the current situation as Incubator podling I would even have a > > lesser bar. In the situation of Wave - complex technology driven by > > less people with less time - the bar should be very low. But this is > > just my opinion. If you agree, work through the mailinglists and > > nominate people. > > > > In general, it needs to be easy to contribute to Wave right now. > > Complex review processes might stop people. I cite Upayavira in the > > hope this thread is more visible: > > > > "= review then commit = > > Mature communities usually follow this, when there's substantial risk in > > making chances. Wave is way to young for this, IMO. > > > > = commit then review = > > This is what I'm used to. Make a commit, and have other developers watch > > the commit list. They can object on the dev list if they see something > > they don't like, but the basic assumption is that, if you have commit > > rights, we trust you." > > > > I am also a fan of ctr. I agree that Wave is ways to young for rtc. > > Instead, code base must move on as quickly as possible. > > > > Please see this e-mail as suggestion, and not binding. > > > > I want to make sure: > > > > - non-committers know they are invited to perform actions > > - committers know its ok to early invite new people to the project > > (don't be shy) > > - there is the option to commit-then-review - no need for a review > > board in early stages, if you ask me > > No need for reviewboard because that's what the commit mails are for. If > you are a committer, make sure you are receiving them and do review > them. > > Upayavira >
