99 lines
3.4 KiB
Markdown
99 lines
3.4 KiB
Markdown
|
---
|
||
|
|
title: Thoughts on Community Management
|
||
|
|
date: 2014-07-31
|
||
|
|
---
|
||
|
|
|
||
|
|
Thoughts on Community Management
|
||
|
|
================================
|
||
|
|
|
||
|
|
Many open source community projects lack proper management. They can put too
|
||
|
|
much of their resources in too few places. When that one person falls out of
|
||
|
|
contact or goes rogue on everyone, it can have huge effects on everyone
|
||
|
|
involved in the project. Users, Contributors and Admins.
|
||
|
|
|
||
|
|
Here, I propose an alternative management structure based on what works.
|
||
|
|
|
||
|
|
## Organization
|
||
|
|
|
||
|
|
Contributors and Project Administrators are there to take input/feedback from
|
||
|
|
Users, rectify the situation or explain why doing so is counterproductive.
|
||
|
|
Doing so will be done kindly and will be ran through at least another person
|
||
|
|
before it is posted publicly. This includes (but is not limited to) email, IRC,
|
||
|
|
forums, anything. A person involved in the project is a representative of it.
|
||
|
|
They are the face of it. If they are rude it taints the image of everyone
|
||
|
|
involved.
|
||
|
|
|
||
|
|
## Access
|
||
|
|
|
||
|
|
Project Administrators will have full, unfiltered access to anything the
|
||
|
|
project has. This includes root access, billing access, everything. There will
|
||
|
|
be no reason to hide things. Operational conversations will be shared. All
|
||
|
|
group decisions will be voted on with a simple Yes/No/Abstain process. As such
|
||
|
|
this team should be kept small.
|
||
|
|
|
||
|
|
## Contributions
|
||
|
|
|
||
|
|
Contributors will have to make pull requests, as will Administrators. There
|
||
|
|
will be review on all changes made. No commits will be pushed to master by
|
||
|
|
themselves unless there is approval. This will allow for the proper review and
|
||
|
|
testing procedures to be done to all code contributed.
|
||
|
|
|
||
|
|
Additionally, for ease of scripts scraping the commits when something is
|
||
|
|
released, a commit style should be enforced.
|
||
|
|
|
||
|
|
### Commit Style
|
||
|
|
|
||
|
|
The following section is borrowed from [Deis' commit
|
||
|
|
guidelines](https://github.com/deis/deis/blob/master/CONTRIBUTING.md).
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
We follow a rough convention for commit messages borrowed from CoreOS, who borrowed theirs
|
||
|
|
from AngularJS. This is an example of a commit:
|
||
|
|
|
||
|
|
feat(scripts/test-cluster): add a cluster test command
|
||
|
|
|
||
|
|
this uses tmux to setup a test cluster that you can easily kill and
|
||
|
|
start for debugging.
|
||
|
|
|
||
|
|
To make it more formal, it looks something like this:
|
||
|
|
|
||
|
|
|
||
|
|
{type}({scope}): {subject}
|
||
|
|
<BLANK LINE>
|
||
|
|
{body}
|
||
|
|
<BLANK LINE>
|
||
|
|
{footer}
|
||
|
|
|
||
|
|
The {scope} can be anything specifying place of the commit change.
|
||
|
|
|
||
|
|
The {subject} needs to use imperative, present tense: “change”, not “changed”
|
||
|
|
nor “changes”. The first letter should not be capitalized, and there is no dot
|
||
|
|
(.) at the end.
|
||
|
|
|
||
|
|
Just like the {subject}, the message {body} needs to be in the present tense,
|
||
|
|
and includes the motivation for the change, as well as a contrast with the
|
||
|
|
previous behavior. The first letter in a paragraph must be capitalized.
|
||
|
|
|
||
|
|
All breaking changes need to be mentioned in the {footer} with the description
|
||
|
|
of the change, the justification behind the change and any migration notes
|
||
|
|
required.
|
||
|
|
|
||
|
|
Any line of the commit message cannot be longer than 72 characters, with the
|
||
|
|
subject line limited to 50 characters. This allows the message to be easier to
|
||
|
|
read on github as well as in various git tools.
|
||
|
|
|
||
|
|
The allowed {types} are as follows:
|
||
|
|
|
||
|
|
feat -> feature
|
||
|
|
fix -> bug fix
|
||
|
|
docs -> documentation
|
||
|
|
style -> formatting
|
||
|
|
ref -> refactoring code
|
||
|
|
test -> adding missing tests
|
||
|
|
chore -> maintenance
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
I believe that these guidelines would lead towards a harmonious community.
|