On Thu, Jul 23, 2015 at 12:19 AM, Branko Čibej <br...@apache.org> wrote:
> >> Concerns have been raised about the people behind the actual commits, > that > >> seems to be left open ? > > I am not sure about this one: why there's a concern that people behind > commits > > aren't the same ppl as making the fixes? Am I reading this right? > > I think there are a couple things to consider here: > > 1. Off-list discussions, and commits made based on such discussions: > There is absolutely nothing wrong with that. The resultant code is > public and can be reviewed. If the reasons behind a change are not > clear, well, it's up to the devs to document the code and/or explain > on the dev@ list; but forbidding off-list discussions implies > forbidding hackathons and ApacheCons, for example. My question was more to do with losing historical detail by squashing commits. Squashing commits has the tendency to hide contributions as well. I think we have a good answer for that. As far as off-list discussions are concerned, this is still a very big issue for me. Off-list discussions and design work is not forbidden, but it must be reflected back to the mailing list. This issue has come up many times. For instance, with Apache Drill, the initial team was highly MapR-centric. This inevitably meant that people talked at lunch or because they sat next to each other. A first step to broaden this discussion and to even the playing field in terms of face to face communication was to institute a weekly video meeting open to everybody via Google hangouts. These meetings are archived, I believe, and there have been over a hundred of them so far. But as good as that outreach was, there was considerable criticism on this same mailing list that hangouts were only OK if the content discussed was either informational (so information travels from the mailing list to the hangouts) or if design decisions were discussed that the discussions were summarized back to the list. Doing this consistently takes considerable effort because it is fairly natural to simply move forward. With perspective, I think that the criticisms and the resulting changes in process in the Drill project were extremely helpful and they make the project better and more approachable. With Ignite, I worry that such discussions are happening (they must be, by geography and time zone alone) but are not being reflected back to the mailing list or to the JIRA. It is not even clear when a bug is closed whether there was a code fix or not.
