Hi Chris, Responses inline On Tue, May 12, 2015 at 10:39 AM, <dev-digest-h...@climate.apache.org> wrote:
> > I don’t think we should dictate everything be code reviewed. 72 hours seems pretty permissive to me. I would comment that I see it as a different case where comments are provided and not addressed. I also don't think that we've seen anything that is so urgent that it cannot withstand a 72 grace period. Is this unreasonable? > I’ve > seen this directly lead to conversations that are relevant to > development being buried in Github. I believe that the issue being referenced here has to do with PR's stagnating due to suggested improvements not being accommodated. Is this not the case? This is what I read. > Take for example your and > Whitehall’s conversation(s) with Kyo that I doubt anyone here has > ever seen since they aren’t even commenting on the Github. Yes, > Github emails are sent to the dev list, my guess is that people > ignore them. > I get batch emails to the ML. This saves me major headache and sometimes it takes a wee while to go through everything. In terms of reading them... yes I do. I read them like I read any other ML message. If and when I can. If I feel it appropriate to comment on GH I will. Likewise, if I feel it appropriate to comment on ML I will. > > On the code review issue - Kyo (or others) shouldn’t have to endlessly > debate or discuss the advantages or disadvantages of this or that > before simply pushing code, and pushing tests. I don't know if anyone is endlessly debating thing are they? I mean there are some community suggestions which have gone unanswered for months. This would lead me to draw the conclusion that there is a strong attempt to obtain consensus but that this cannot be done in a silent manner. There needs to be correspondence on what is the right thing to do. We've all had patches which take months to get in to a codebase. We've all got loads of examples lying around. I don't really see thsi as a biggie. What I do see is a biggie is that a consensual approach is what will work best for OCW community. > My general rule of > thumb is that there are CTR and RTC workflows and use cases for > both. RTC works great when it’s possibly controversial or when you > really want someone’s eyes on your code for review. However it’s > also overhead that I do not believe is needed if a developer wants > to push forward and scratch his or her itch, in an area of the > codebase that they are working on. The codebase is factored out > enough reasonably well so that people can work on things in parallel > and independently. When in doubt, ask. > Absolutely. I don't see that 72 hours block this in any way shape or form. Does anyone else? > > I’m also pretty worried since anyone that looks at the Git and > project history over the last year can easily see that Mike has > pretty much been doing the bulk load of the pushing and code > committing here. Yep. Mike has been merging for people. Committing a bunch himself (after usually waiting the 72 hours) and also PMC lead with a vetted interest in mapping OCW directly to his day-to-day job so this would make logical sense to me. I share your concern however it is no surprise to me that the stats tell the tale they do. > Kim’s stepped up recently as has Kyo, which is > 3 people, which is great, but I’m worried about a project with > a small number of active developers (really 1 major) imposing > RTC - I don’t have time to look up citations but you are free > to scope these out over the ASF archives. If 72 hours grace period (because that's what I see it as coming down to) is too long then we need to seriously consider why. > RTC on smaller projects > just leads to barriers. We need to be flexible and make it inviting > for at the very least, our own developers to contribute to the project, > let along attracting new people. The workflow has 2 steps. 1) Log an issue and provide a PR 2) Wait 72 hours before committing (lazy consensus). I would suggest that we augment the workflow to accomodate a thirst step 3) Please make best efforts to at least consider other community comments before merging. This way we can work collaboratively to all have a better understanding of the codebase. > Ross was elected in December 2014, > which is great, but we need to do better. > > Certainly. OCW fills a very niche area though which we are all aware of. It is a non-traditional Apache project filling one of few pure science oriented TLP's. The fact that there are few committers on the project is not to me any huge surprise either. Not everyone is working with scientific data. If you are not then you have absolutely no incentive to use OCW. Additionally, if we have a problem with community outreach then I say we should make an attempt to address that on it's own. Lets be careful not to munge these issues into one... simply because they are not. If the two stage workflow is not working or if it is causing barriers then we need to address it. I am struggling to see how it can be causing barriers. The issues may be that there needs to be clarification on implicit expectations which come bundled within those two stages. Hopefully I've communicated some of my points here. Lets kep this going. Thanks Lewis
