OpenBEL code contribution guidelines

[William Hayes]

Hi all,

We need to codify the OpenBEL code contributions protocol.  

Here is what I'm proposing:

• Provide code submissions/fixes as pull requests (PR's) associated with a Github repository issue
• Squash commits prior to submission
• Contributor needs to have a signed CLA (individual or corporate)

Submitting the PR against an issue provides an opportunity to share your plans to work on an issue and have it assigned to you and get feedback on a proposed enhancement to increase the likelihood of a successful PR.  I don't think we should require this, but it's best practice in my mind.

There are some interesting projects to track CLA's, e.g. cla-bot, cla-enforcer, clahub.com, cla-assistant.io  

We can modify the Apache Individual and Corporate CLA’s for OpenBEL.  Any recommendations on how to manage CLA’s – track them in a github repo or via one of the CLA tools?  I'd prefer something that doesn't require me to administer :) and doesn't slow down PR's which pretty much requires automation or an easy way to submit/confirm CLA's by the repo manager accepting the PR.  Has anyone seen a process/protocol for this that they liked?

Thoughts, suggestions, changes?  Hoping to have the first version of this policy deployed by this Wednesday.

Enjoy your weekend!

William

[Anthony Bargnesi]

William,

Thanks for this outline. This looks great.

I would remove the squash commit guideline. Multiple commits may be used in a logical way by the contributor that allows for a better discussion on the PR. If the commit history is messy then the opened PR is a great chance to discuss why a squash would be appropriate.

Also, overall, I would prefer to see less barriers to contribution.

CLA integration might make a lot of sense in the long run, but for now we can obtain and track manually. The contributor experience of clihub.com does look simple though.

We should also provide a central contributors documentation for OpenBEL as a whole. This could be hosted on openbel.github.io.

- tony

---

From: openbel...@googlegroups.com <openbel...@googlegroups.com> on behalf of William Hayes <william...@gmail.com>
Sent: Friday, October 30, 2015 3:00 PM
To: openbel-discuss
Subject: OpenBEL code contribution guidelines

 

--
You received this message because you are subscribed to the Google Groups "openbel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbel-discu...@googlegroups.com.
To post to this group, send email to openbel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openbel-discuss/cf0f80da-518c-4399-af0a-c183b0abef95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Bargnesi]

PRs associated with an issue are great practice, but sometimes creating an issue is more of an impediment. Like with small, obvious changes. I think we should be more explicit here. Regarding squash commits, they are a bit unwieldy to novices, I'd recommend eliminating this clause altogether. Once our repositories mature, we can reevaluate the more stringent requirements.

This will also allow PRs to address more than one issue at once, rather than asking for individual PRs per issue.

Here's my modifications:

• Provide code submissions/fixes as pull requests (PRs)
• If the PR addresses a particular issue, mention the issue in the pull request.
  

• Contributor needs to have a signed CLA (individual or corporate)

William Hayes wrote:

--
You received this message because you are subscribed to the Google Groups "openbel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbel-discu...@googlegroups.com.
To post to this group, send email to openbel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openbel-discuss/cf0f80da-518c-4399-af0a-c183b0abef95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Nick Bargnesi
Application Architect
Selventa ® I T: +1 (401) 378-4290
One Alewife Center
Cambridge, MA

[William Hayes]

I've put these recommendations into https://openbel.github.io

[Anthony Bargnesi]

I looked into the CLA offerings clahub and cla-assistant a bit.

The clahub project is looking for new maintainers and does not have import/export of contributors. See issue #111.

Now cla-assistant looks better. The main site is hosted, but an individual instance could be set up if need be (open source). They boast a simple experience based on the CLA existing in a GitHub Gist and PR used to initiate the action to the contributor.

I vote we try cla-assistant.