React-native-mapbox-gl: Ways of Working

[kristfal]

Hey,

as this project becomes more community driven than before, we should define some ways of working to maintain/improve the quality and development speed of the repo.

As an OS project, this repo lacks some aspects that may/will make the lives of maintainers easier. These include (but may not be limited to):

1) Issue template:

a) To keep questions out of Github, the template should link to gitter and stackoverflow
b) We need users to specify version of react-native-mapbox-gl and RN

2) CI/CD:

a) We should run unit tests on all PRs and master
b) We should run E2E tests on the example app (we have a quite good experience using Detox)

3) Coding styles:

a) We now use Prettier and ESLint. Is there anything equivalent for Java and Obj-C that we should use?

To maintainers: Any thoughts on this and other aspects of the repo?

[samdelacruz]

All sounds reasonable, however I tend to disagree with 1a. Questions being raised in GitHub are an indication of a need for better documentation - and answering the questions on the issue provides an easy way for subsequent users to find answers more quickly than waiting for a response in gitter. They can be a prompt for raising documentation issues. IMO it's better to keep information in one place, rather than scattered around the web in different services.

[nitaliano]

• Release cadence, we should release master to npm once a week on the same day and just make it a habit. This is something I can own and maybe a few others can be given access to our npm package.
• Issue templates are something we badly need.
• Gitbot to help close old and stale issues
• We should use the same linting tools that are used in gl-native so we stay consistent
• Use gh-pages for a doc site, since I don't think Mapbox will have enough resources to get this on our doc site and keep it up to date. This will also encourage members in the OS community to help make the docs as good as they can be

[onitzschke]

I totally agree with you.