CONTRIBUTING.md

Table of Contents

• Community Guidelines
• The Basics of Contributing
• Opening Issues
  • Feature Requests
  • Bug Reports
• Submitting Merge Requests
• Reviewing Merge Requests
• Style preferences
• Talking to humans

Community Guidelines

Hi, we're so glad you're here! Team Friendo is trying to make software for liberation instead of exploitation and profit. As such, it is important to us that the principles of anti-oppression, consent, solidarity, empowerment, and autonomy that we want to see in the world are also present in the community we build to make the tools we want to put into the world.

We want everyone to be good to one another, we want to have clear definitions of what we think that means, and clear recourses you can take if you feel the community is not upholding its values in a way that makes you feel disempowered or unsafe.

Toward that end, we are currently drafting a code of conduct, which should be live shortly. You can read it in draft form here:

http://our.solidarity.camp/s/QMRYJJ9eLYCawby

As a baseline set of norms, we would also encourage you to read and abide by the Recurse Center Social Rules, the main point of which is to make people feel very safe asking questions and seeking help from others, which we'd really like to encourage here on Team Friendo:

https://www.recurse.com/social-rules

The Basics of Contributing

Carefully reading the entire contributor guide below will greatly increase the chances that we can accept your merge request, but to get you started here's the basics of what ask of you.

• Contact us if you've got questions, we are friendly. Open an issue or email us email: team-friendo [at] riseup [dot] net, gpg fingerprint: 2EEAFF8BD61D568E2A3168AAE726A156229F56F1
• Open a feature or bug report issue for your code so we can support you and be prepared for the coming merge request. Please tag either @aguestuser or @margot so we see it. We provide ideal helpful issue/bug report templates below.
• Use your issue id in your branch naming and commit messages eg: 99-add-lollipops-branch / "[99] adds the red pops in cherry flavor"
• Please rebase master into your branch before you create a merge request, we prefer rebase to merge.
• If possible please write or extend exiting unit tests.
• Please use ES6 style JS and features: https://ponyfoo.com/articles/es6
• Please run tests before submitting your merge request (see make test.all and other make test.x utilities) this will also run a lint, run make test.lint-fix to just automatically tidy formatting.
• Make a merge request and tag either @aguestuser or @fdbk -- we will try to review as soon as we can.

Details about each of these points are below.

Opening Issues

Before opening any issue, please check the project's issue board to make sure somebody hasn't already requested the same thing. Maybe you could get the same effect by giving a to an already existing issue, or by adding your voice to the discussion about whether or not to implement another request! :)

Feature Requests

If you are reporting a feature request, please:

• Tag the issue with a Feature Request tag so we can prioritize it alongside other feature requests
• Explain in as much detail as you can the social circumstances that cause you to want to have this feature
  • What goal were you trying to accomplish in the world?
  • Why was signalboost as designed incapable of accomplishing those goals?
  • Why are those goals particularly urgent for your group? Ie: why is it important to prioritize making this feature ahead of other features?
  • Here's an example: "We were sending out requests for people to sign up for roles for a march. But nobody could respond to sign up for roles. Can you add a way for subscribers?"
• Try to emphasize the human needs that the feature would address rather than the technical solution you envision meeting those needs
  • Ie: instead of "I want signalboost to auto-invite everyone in my contact list" say "I need a way to help people who don't know about signalboost join a channel I just made"
  • This style often more clearly illuminates the problem and in so doing, often leads to more creative/imaginative solutions than if we started by thinking of the solution first! :)

If you are on Team Friendo (or feel like being extra-helpful), please use this format:

# Value

{{ why is this feature important? who needs it in the world? why should we prioritize implementing it? }}

# Behavior

GIVEN {{ some preexisting set of conditions }}
* WHEN {{ some action is take }}
* THEN {{ some observable state change should occur }}

# Implementation Notes

{{ any technical details about how to implement the feature }}
{{ any data model changes you think it would be useful to spell out }}
{{ any definitions you found it useful to shorthand in the "Behavior" section }}
{{ any hidden complexity, context, or gotchas you think it would be useful to make explicit for someone coming to the issue without context }}

# Context

{{ anything we should explicitly descope??}}
{{ anything about the discussion with users that caused us to create this issue that might be non-obvious?? }}