Re: [DISCUSS] Development Process
Dylan Bethune-Waddell <dylan.bet...@...>
toggle quoted messageShow quoted text
Thanks for getting this discussion started - I personally like the idea of following the TinkerPop/Apache Way for accepting/rejecting changes, but I'm not familiar with alternatives so I'm looking forward to hearing from others on that. One thing I will say is that I believe the approval of a specific person should be required at times, but only by the request of the person proposing/committing a "big change", or at the request of another committer so long as that request for a specific pair of eyes on is not vetoed by a 3+ vote from other committers. I'm imagining situations in which the current maintainer is indisposed but should (or shouldn't) look at it, or situations in which the benevolent dictator of such and such feature throws a fit and starts vetoing the will of the people. Mostly joking - but it is my understanding no-one should get benevolent dictatorships in FOSS because sometimes weird things do happen.
Regarding new features and design discussions, I like what I have seen on the Mesos JIRA before, where a link is posted in the parent JIRA issue to a public Google Docs design document where editing/discussion can take place. The Google Docs approach for "Technical Steering" seems good to me because it is (a) flexible enough to detail anything, (b) in the public eye, and (c) provides an opportunity for the same kind of line-by-line review/discuss iteration we can do on github for code but can't really do on github for arbitrary documents (that would be crazy... right?). Along the same lines I liked this Google Sheet that WikiMedia produced to compare alternatives when they were looking for a graph database to back their query service after Titan was acquired by DataStax. This would also make the definition of "big change" pretty clear, as we define anything requiring a design doc (complete with 3+ committer vote if requirement of doc in dispute) "big", and everything else not. I could imagine us doing something similar when considering new backends/libraries and such. Generally I like the link-out to Google Docs approach because issues of design are usefully separated from development.
We might also want to use JIRA (and apply for an open source license to get it hosted by Atlassian), which I am in favour of because I believe JanusGraph consists of enough moving pieces and sub-projects that in the long run setting it up will benefit us as compared to git issue tracking/management - it is my fear that at some point, what is provided by github (just labels and links mostly, no?) will not be sufficient to properly delineate issues and efforts within the project and migrating to something like JIRA will no longer be trivial, and may even be infeasible after a year or two.
What do others think?
On Tuesday, January 24, 2017 at 9:18:00 AM UTC-5, Ted Wilmes wrote: