A couple of points to consider:

+1 policy for commits:
A lot of Apache projects have guidelines for how long a pull request must be open before it can be merged. Guidelines typically range from 24-72 hours after opening, or after the last code change commit in the pull request. The idea is that with a community spread out over many timezones, it’s best to let the earth rotate at least once so everyone has a chance to review the change during their working hours.

For -1 votes (vetoes) on code changes, a lot of projects specify that it must be accompanied by a justification. Without a justification the veto is invalid.


Project Direction:
I would suggest a guideline that all decision-making take place on the mailing list (similar to the ASF mantra “if it didn’t happen on an email list, id didn’t happen”). Gitter is fine for informal communication, questions, etc., but any project-related decisions should be brought to the mailing lists. An again, a waiting period for decisions gives everyone in the community a chance to participate.

I’m also in favor of some sort of “JanusGraph Improvement Proposal" (JIP) (modeled similarly for Apache Kafka’s KIP process) for large changes. It’s a good way to get community feedback for big changes.

Feature Branches:
Another idea I support. In Apache Storm we use feature branches as sort of a “distributed pull request” — commit rules are relaxed for those branches, and when the feature is complete and ready to be merged to a main branch, the changes go up for review with the same merge rules as a main branch.

Pull Request Templates:
It’s good to have guidelines around what information needs to go into a pull request title and description. Otherwise you will inevitably get pull requests with a title like “fix bug” and no description, which forces you to look at the code changes

-Taylor