Guidelines for contributing about pelias

[KathleenLD]

👍 on it

[missinglink]

github: Setting guidelines for repository contributors

[KathleenLD]

that was easy

[KathleenLD]

Ok, I'm getting this started here: https://github.com/pelias/pelias/blob/contribution/CONTRIBUTING.md

@missinglink how do you prefer to receive PRs? Do you want me to open a WIP PR now, or wait until I've got some actual content?

Speaking of content, what would you like to have included in this? My thoughts are:

• Guidance for opening issues
  • Look through old issues
  • Point to guidance on writing good bug reports
  • Explain the bug clearly
  • How to reproduce?
  • What result did you get?
  • What result did you expect?
  • Provide links, screenshots, and system information when possible
• Guidance for contributing to the project
  • Any CircleCI guidance?
  • Style standards?
  • Where to look for the current roadmap (I assume this doesn't exist yet)

I'll start adding some of this to that branch. Let me know how you'd like me to proceed in terms of collaborating on this.

[missinglink]

hey @KathleenLD, a WIP PR is fine as long as it's merged in a reasonable timeframe (~1 week).
Please clearly mark a WIP PR with 'DO NOT MERGE' followed by a short reason or description.

This workflow just kind of came about, but seems to work for us, eg: pelias/api#60

---

• Expected/Actual and Reproducibility are the most important.
• Search is geographically biased so we need to know where the consuming software said they were.
• Without local knowledge we don't know what was supposed to be returned and searching osm/bing/google whatever is time-consuming.
• Attaching a link to an above source is fantastic.

Things like language/terminology and being too picky about grammar etc. is not of any concern, I would like people to feel comfortable that they can report issues without being at risk of public shaming.

In that regards, I think we should have a basic 'being human' section about not putting people down or being horrible, valuing objectivity over subjectivity, just generally being compassionate, especially with foreign language related bug reports (which we very much welcome).

All the things you mentioned above are awesome, let's get it started and then iterate it to awesome rather than trying to nail it all the first go.

[missinglink]

Here is a perfect example of the sort of issue where we could have helped to shape the conversation better: mapzen/open#357

[sevko]

Talked with @KathleenLD about this, and the first step is probably to set up a Pelias project template so that contributors can spawn new packages and have things Just Work, without having to instantiate all the boilerplate (package.json, .travis.yml, etc.). cc @hkrishna , @dianashk

[KathleenLD]

Closing this out-- CONTRIBUTING.md is live.