Wednesday 22 June 2016

How to share collaboratively

Following on:

When contributing to mailing lists and fora:
  • Contribute constructively - no one likes to be told "You've got a REALLY ugly baby there" or equivalent.
  • Think through what you post: check references and check that it reads clearly and is spelled correctly
  • Add value
 When contributing bug reports:
  •  Provide as full details of hardware and software as you have
  • Answer questions carefully: Ask questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html
  • Be prepared to follow up queries / provide sufficient evidence to reproduce behaviour or provide pathological test cases 
  • Provide a patch if possible: even if it's only pseudocode
When adding to / modifying FLOSS software:
  • Keep pristine sources that you have downloaded
  • Maintain patch series against pristine source
  • Talk to the originators of the software / current maintainers elsewhere
  • Follow upstream style if feasible / a consistent house style if not
  • Be generous in what you accept: be precise in what you put out
  • Don't produce licence conflicts - check and check again that your software can be distributed.
  • Don't apply inconsistent copyrights
When writing new FLOSS software / "freeing" prior commercial/closed code under a FLOSS licence
  • Make permissions explicit and publish under a well established FLOSS licence 
  • Be generous to potential contributors and collaborators: render them every assistance so that they can help you better
  • Be generous in what you accept: be precise in what you put out
  • Don't produce licence conflicts - check and check again that your software can be distributed.
  • Don't apply inconsistent copyrights: software you write is your copyright at the outset until you assign it elsewhere
  • Contribute documentation / examples
  • Maintain a bugtracker and mailing lists for your software
If you are required to sign a contributor license agreement [CLA]
  • Ensure that you have the rights you purport to assign
  • Assign the minimum of rights necessary - if you can continue to allow full and free use of your code, do so
  • Meet any  required code of conduct [CoC] stipulations in addition to the CLA
Always remember in all of this: just because you understand your code and your working practices doesn't mean that anyone else will.
There is no automatic right to contribution nor any necessary assumption or precondition that collaborators will come forward.
Just because you love your own code doesn't mean that it merits anyone else's interest or that anyone else should value it thereby
"Just because it scratches your itch doesn't mean that it scratches anyone else's - or that it's actually any good / any use to anyone else"

No comments:

Post a Comment