>> 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). >
