Skip to content

Instantly share code, notes, and snippets.

@UncleCJ
Last active November 6, 2017 11:53
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save UncleCJ/5eeefe46dd5bb07584d3358d58f0a03d to your computer and use it in GitHub Desktop.
Save UncleCJ/5eeefe46dd5bb07584d3358d58f0a03d to your computer and use it in GitHub Desktop.

I aim to bundle something together with these:

Now I think I need to write about ownership and flows...

Collaboration and ownership

Ok, so you want to create something collaboratively - the normal way is to share a Google Doc (or, slightly better, a folder) and hack away. If you really have decided to work for a common project, there might even exist a wiki to which you encourage others to contribute.

To be clear, collaboration can be both fast, real-time or slow, asynchronous. These thoughts deal more with the latter, the long-term aspects of collaboration. For the real-time collaboration a suggestion is to prefer simple tools such as Etherpad that less influence long term matters of ownership.

Assuming you manage to attract some attention to your project, the results commonly go in one direction - others will contribute for a while, but attention dwindle and eventually you are left alone with the material, at worst even with questionable authority for how you may use it or restart collaboration.

A factor that may play into this is that you have invited others to contribute to your thing, retaining ownership, credit and responsibility for it. Here the way Github works is critically different - the first step is for contributors to make the material their own, then possibly contribute to it and eventually suggest that you as coordinator consider including their contribution in your product.

This is the way Github accelerated Open Source development - rather than as previously (commonly using the tool "Subversion") arbitrarily deciding who would have access to edit the material, everyone get access to fork the project and the authoritative decision whether to include the contribution is postponed until there is something tangible to consider.

The beneficial side effect of working with pull rather than push like this is that contributors get to show off their contribution and involvement - at least if they accept the publicity, activity is visible in their Github profiles rather than only the particular projects they are contributing to. Their efforts remain their own and may be included in a greater whole.

Transparency and background energy

The account and familiarity hurdle

Attention for debating or creating

Doocracy...

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