puddle

Puddle

The Perth Gophers Slackbot Mud Project

Introduction

This is Puddle, the Perth Gopher's collaborative project. Created to help us learn Go and to teach others Go.

Puddle is a mud. Puddle is a slackbot. Puddle is a slackbot mud. How do we design a Mud? Messily.

• Mud Design concepts
• How do Muds work?
• Similar project for inspiration

This project will grow organically, and therefore it'll be an absolute mess. This is OK.

Spinup

Go 1.6 and above is required for this project.

$ go get github.com/perthgophers/puddle
$ go get github.com/Masterminds/glide
$ cd  $GOPATH/src/github.com/perthgophers/puddle
$ glide install
$ SLACKTOKEN=<SLACK_API_TOKEN> go run main.go

Collaborative etiquette

This project is an Open Source project encouraging everyone to be fearless in their contributions. This document lists some ground rules to foster a happy collaborative atmosphere.

• Individuals making valuable contributions are added as collaborators (commit access).

• This project is more like an open wiki than a standard guarded project.

For issue reporters and feature requests

• Use labels! Use your judgement to figure out how difficult the issue is. Level 1 is for noobs, level 2 is for those proficient Go concepts such as channels & pointers, level 3 is reserved for those that are Godlike, or want to be.

• Don't be afraid! You don't need to submit code to contribute to the success of a project! Don't hold back on submitting issues, commenting on discussions and helping people out.

• Tell us everything. When filing bug reports, be generous in the details: environment, OS, browser, steps to replicate, and so on.

For contributors

• Check development notes. Any details on setting up a development environment, running tests, releasing versions and such are kept in a file like NOTES.md.

• Be a good citizen. Try your best to adhere to the established styles of the project. This doesn't mean that you shouldn't break them, but be prepared to have a reason if you do.

• Document exported functions & variables!. All exported names must be documented. If you've added some complex features, please update this document with instructions on how it works, and how other contributors interact with it.

• Be informative. Format your pull requests nicely. Include screenshots if applicable.

• Don't Panic. This project is going to be messy. Don't be afraid of submitting any code, even if you yourself think it's absolutely terrible. This is, above all else, a learning project.

For collaborators

Individuals making valuable contributions are encouraged to be added as collaborators (commit access). This status should be given liberally. If things break, we don't care. Someone will fix it, and then give a valuable critique of your code!

• Work in branches then send a PR. Just because you have full commit access doesn't mean you shouldn't use pull requests. PRs are a great way to solicit feedback from co-collaborators and to give them a nice overview of what's going on.

• Review outstanding PRs. Feel free to merge any you see fit, and leave comments on anything that needs revisions. If you don't feel comfortable merging them, at least comment with a :+1: to signal your co-collaborators that it's passed your review.

• Push directly for micro-fixes only. Only push to master for trivial updates that would be too noisy to notify your teammates of, such as typo fixes.

• You can self-merge your PRs. Sometimes the rest of the team may be inactive, in which case, use your best judgement to self-merge PRs. If you mess it up, so what?

• Keep history clean. No --force pushing on branches that aren't yours. No --force pushing at all, please.

• Communicate. You can use GitHub issues to communicate with your co-collaborators. Feel free to @mention them in issues. You can also chat in the #puddle channel on Slack.

• Be nice. The collaborator team is nice, so we are all nice. Don't be an asshole to anyone or you'll be fired, from a cannon, into the sun.

For founders

• Set up continuous-integration. A CI service like [Travis] will inspect PR's so you don't have to.

• Be decisive. Don't be afraid to put your foot down on issues like design decisions.

• Thank people. People put in their hard work. Gratitude goes a long way.

• Be nice. The open source community is nice, so we are nice.

Acknowledgements

Thank you to the Perth Gophers community.