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
