1. Janusgraph-Dev
  2. Messages

Re: [DISCUSS] Development Process

Dylan Bethune-Waddell <dylan.bet...@...>
 

Hi Ted,

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:
Hello,
I'd like to hear what folks think about development process for JanusGraph.  I think
it would be helpful if we had some basic guidelines documented.

I'll throw a few ideas out to get the brainstorming going.

Proposed Functionality and Project Direction
-----------------------------------------------------------
Proposed functionality should be discussed on the dev list.  If it is a large change (how 
should we define large?), it should be voted on requiring 3 +1 votes from project committers.  
I could see one example of a large change as adding a new storage adapter.  Bug fixes 
and enhancements that do not change APIs nor require large amount of refactoring 
should not require a vote.


Pull Requests
-------------------
I think the Apache TinkerPop project could be one source of inspiration for our dev 
processes [1].  For PRs in particular, votes are required before a PR can be merged.  
3 votes by committers are required and the submitter can (and usually does) vote for 
their own PR if they are a committer.  Since we have folks tagged as "maintainers" for 
the different modules of JanusGraph, maybe we could also require one of the votes
to come from the relevant module maintainer.

On the other end of the spectrum, we could lower the vote requirement or allow for
commit than review (CTR), skipping votes altogether.  We could also stick with voting
but allow for CTR when a committer deems a PR low risk.

Thoughts?
Ted 

Join {janusgraph-dev@lists.lfaidata.foundation to automatically receive all group messages.