make a contribution guide

[busbey]

Make a short guide for new contributors

• include pointers to get access to code, issue tracker, mailing list
• include style guide
• include pr guidance
• include licensing guidance
• include expectations around releases

[busbey]

Are we review then commit, @cmccoy? I'd be in favor of adopting it as our policy.

For folks who aren't familiar, that would mean maintainers are on the same footing as other contributors: someone else has to agree that a change is ready for merge before things are pushed into the main repo.

Given our current low maintainer count, I'd be fine with accepting community reviews as authoritative (regardless they'd be lovely to have).

[cmccoy]

On May 23, 2015 8:17 AM, "Sean Busbey" notifications@github.com wrote:

Are we review then commit, @cmccoy? I'd be in favor of adopting it as our
policy.

Me too, especially for code changes.
I'm heading out if town for the weekend, but will catch up Monday or so.

For folks who aren't familiar, that would mean maintainers are on the
same footing as other contributors: someone else has to agree that a change
is ready for merge before things are pushed into the main repo.

Given our current low maintainer count, I'd be fine with accepting
community reviews as authoritative (regardless they'd be lovely to have).

—
Reply to this email directly or view it on GitHub.

[busbey]

include expectations for adding new bindings / workloads

• require a README that walks through running a load and a workload (for both bindings and workloads)
• javadocs
• example properties

[busbey]

make sure to remind folks that we expect to work on Windows

[kruthar]

Additional note as per @busbey comments on #500.

YCSB clients should default to the strictest consistency available and document consistency tuning and tradeoffs in their readme.

[busbey]

other guidance that I don't see above that we've discussed:

• no client side buffering by default (but if you allow it please document how to use it and the tradeoffs)
• document which specific version(s) of the datastore you expect to work with
• document any set up of the datastore needed (like how some systems need to create a table with a particular schema)

[risdenk]

As noted in #596:

in general bindings should be in their own package

[risdenk]

We should just make a CONTRIBUTING.md and have Github handle displaying it. https://github.com/blog/1184-contributing-guidelines