Adding first draft of contributing guidelines #1912

Merged
merged 3 commits into from Sep 18, 2012

Conversation

Projects
None yet
4 participants
@jc00ke
Member

jc00ke commented Sep 17, 2012

Github just pushed the contributing guidelines feature:
https://github.com/blog/1184-contributing-guidelines

@brixen @dbussink @evanphx thoughts?

@dbussink

This comment has been minimized.

Show comment Hide comment
@dbussink

dbussink Sep 17, 2012

Member

Ok, few initial thoughts:

  • Add a request for a reproduction of the issue. It is usually not very useful if people report a crash / bug without telling us how they got it. This often results in going back and forth in the issue before we have something actionable. Basically the smaller / easier the repro, the faster it is fixed usually. Issues without a way to reproduce them often linger around for a long time.
  • If you add a spec and a bugfix, it's not necessary to also add tags. We don't have an explicit guarantee that every commit should be green, but just that every push / merge should be. We don't want to add that overhead to contributors if it's not necessary.
  • Maybe add a comment on style for larger commit messages? So have a single line title message up to (I think) 80 characters (my vim setup actually shows when I go over it, so don't know the actual limit) and use separate paragraphs afterwards for more detail.
Member

dbussink commented Sep 17, 2012

Ok, few initial thoughts:

  • Add a request for a reproduction of the issue. It is usually not very useful if people report a crash / bug without telling us how they got it. This often results in going back and forth in the issue before we have something actionable. Basically the smaller / easier the repro, the faster it is fixed usually. Issues without a way to reproduce them often linger around for a long time.
  • If you add a spec and a bugfix, it's not necessary to also add tags. We don't have an explicit guarantee that every commit should be green, but just that every push / merge should be. We don't want to add that overhead to contributors if it's not necessary.
  • Maybe add a comment on style for larger commit messages? So have a single line title message up to (I think) 80 characters (my vim setup actually shows when I go over it, so don't know the actual limit) and use separate paragraphs afterwards for more detail.
@leavengood

This comment has been minimized.

Show comment Hide comment
@leavengood

leavengood Sep 17, 2012

Member

To respond to the last bullet point from dbussink, generally the first line in Git should not be more than 50 characters. Here is some general advice on Git commit messages:

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Member

leavengood commented Sep 17, 2012

To respond to the last bullet point from dbussink, generally the first line in Git should not be more than 50 characters. Here is some general advice on Git commit messages:

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

@jc00ke

This comment has been minimized.

Show comment Hide comment
@jc00ke

jc00ke Sep 17, 2012

Member

I prefer @tpope's method.

Member

jc00ke commented Sep 17, 2012

I prefer @tpope's method.

CONTRIBUTING.md
@@ -0,0 +1,37 @@
+# Thanks!
+
+We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue.

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Sep 18, 2012

Could we break this line up into multiple lines? (e.g: a paragraph split by newlines).
On smaller screens this forces horizontal scrolling, which sucks :P

@ghost

ghost Sep 18, 2012

Could we break this line up into multiple lines? (e.g: a paragraph split by newlines).
On smaller screens this forces horizontal scrolling, which sucks :P

CONTRIBUTING.md
+
+1. Fork the repo
+1. Create a topic branch
+1. Include a spec, if appropriate. Pull requests that need a spec but are submitted without one will be delayed until one is written. The spec should be in a separate commit.

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Sep 18, 2012

Same here, can this be broken up into multiple lines?

@ghost

ghost Sep 18, 2012

Same here, can this be broken up into multiple lines?

@carlosgaldino

This comment has been minimized.

Show comment Hide comment
@carlosgaldino

carlosgaldino Sep 18, 2012

Member

Since this branch was public I took the liberty of splitting the long lines.

@jc00ke
I hope you don't mind. =)

Member

carlosgaldino commented Sep 18, 2012

Since this branch was public I took the liberty of splitting the long lines.

@jc00ke
I hope you don't mind. =)

@jc00ke

This comment has been minimized.

Show comment Hide comment
@jc00ke

jc00ke Sep 18, 2012

Member

Nope, I don't mind at all! When I was typing that line out it felt long, but I wasn't sure if it would wrap or scroll on GH.

I think this is a good start. I'll merge now, and we can change if needed.

Member

jc00ke commented Sep 18, 2012

Nope, I don't mind at all! When I was typing that line out it felt long, but I wasn't sure if it would wrap or scroll on GH.

I think this is a good start. I'll merge now, and we can change if needed.

jc00ke added a commit that referenced this pull request Sep 18, 2012

Merge pull request #1912 from rubinius/contributing-guidelines
Adding first draft of contributing guidelines

@jc00ke jc00ke merged commit 6de070e into master Sep 18, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment