Hi Guys, It's up to you. I've never been a fan of project bylaws.
To me they "anticipate" things needing clarifying whereas to me, the discussions on list, the meetings at ApacheCon, the day to day interactions that occur however, are much more socially fun, and wholly enjoyable to participate in then: "According to bylaw G, you are an X committer, in a year, you can become a PMC member, etc." "Per the bylaws, which are different than the general Apache guidelines, VOTEs are required to have a x/4 majority, except for Tuesday, on which" blah blah blah http://www.apache.org/foundation/how-it-works.html http://www.apache.org/foundation/voting.html http://incubator.apache.org/guides/ppmc.html http://www.apache.org/dev/committers.html Anyone object to simply stating those above along with social graces, and communication, are the bylaws for the project? Some people and projects feel the need to develop these specifically for those projects, however every time I see that, I see extra conversation, exclusion,and other things that don't' encourage me to work on those projects. TL;DR Cheers, Chris On 3/19/13 11:18 AM, "Henry Saputra" <[email protected]> wrote: >>> We need to get Tajo into easy to contribute stage with good >documentations >>> and good build scripts/tools. >>> >>This is not in any way in conflict with RTC. >> >Hmm I was actually thinking more about comments or alignment cleanups that >wont affect any changes to the code. >I know like ZK prefer to be "dirty" but works and some projects like Shiro >has very good code comments and neat alignments. >My point was these kind of changes may not need review at all. >I want to hear about community comment to avoid conflict of large commits >that dont change flow of the code at all in the early stage bringing the >source code to good shape. > >Community has spoken so standard RTC it is =) > >Another question, especially for mentors, should we have bylaws setup >early >or should we wait a bit longer? > > >- Henry > > >On Tue, Mar 19, 2013 at 10:32 AM, Jakob Homan <[email protected]> wrote: > >> +1 to standard RTC with reviews before all commits excepting those >> necessary to fix a broken build. >> >> On Tue, Mar 19, 2013 at 10:13 AM, Henry Saputra <[email protected] >> >wrote: >> >> > I like the RTC but I believe we should not be too strict about it in >>the >> > early phase of incubating project. >> > >> It's not about being strict, it's about establishing a culture and >> community norms. >> >> >> > We need to get Tajo into easy to contribute stage with good >> documentations >> > and good build scripts/tools. >> > >> This is not in any way in conflict with RTC. >> >> > >> > I would say we use RTC with common sense. If you are in doubt fire >>JIRA + >> > review. Especially when half of the team are split between day and >>night >> =) >> >> Geographically dispersed teams is a better reason to use RTC as it gives >> those still asleep a chance to look at the code before it goes in, >>avoiding >> the cost of reverting. >> >> Henry, it looks like there's pretty strong consensus to standard RTC >>with >> 6x+1 for it and Chris' -0 (is that a good characterization, Chris). >>
