Update the contribution guidelines.

This commit is contained in:
Joshua Lund 2018-05-21 18:38:58 -06:00 committed by Michael Kirk
parent 9155a82b65
commit 5d312220ab
1 changed files with 63 additions and 34 deletions

View File

@ -1,55 +1,84 @@
## Contributor agreement
# Contributing to Signal iOS
Apple requires contributors to iOS projects to relicense their code on submit. We'll have to have individual contributors sign something to enable this.
Thank you for supporting Signal and looking for ways to help. Please note that some conventions here might be a bit different than what you are used to, even if you have contributed to other open source projects before. Reading this document will help you save time and work effectively with the developers and other contributors.
Our volunteer legal have put together a form you can sign electronically. So no scanning, faxing, or carrier pigeons involved. How modern:
https://signal.org/cla/
Please go ahead and sign, putting your github username in "Address line #2", so that we can accept your pull requests at our heart's delight.
## Development Ideology
## Code Conventions
Truths which we believe to be self-evident:
To get started with developing for Signal iOS, please read [this tutorial on git best practices](https://gist.github.com/corbett/ef9fd5f1abbef3b02f3b).
1. **The answer is not more options.** If you feel compelled to add a preference that's exposed to the user, it's very possible you've made a wrong turn somewhere.
1. **The user doesn't know what a key is.** We need to minimize the points at which a user is exposed to this sort of terminology as extremely as possible.
1. **There are no power users.** The idea that some users "understand" concepts better than others has proven to be, for the most part, false. If anything, "power users" are more dangerous than the rest, and we should avoid exposing dangerous functionality to them.
1. **If it's "like PGP," it's wrong.** PGP is our guide for what not to do.
1. **It's an asynchronous world.** Be wary of anything that is anti-asynchronous: ACKs, protocol confirmations, or any protocol-level "advisory" message.
1. **There is no such thing as time.** Protocol ideas that require synchronized clocks are doomed to failure.
We are trying to follow the [GitHub code conventions for Objective-C](https://github.com/github/objective-c-conventions) and we appreciate that pull requests do conform with those conventions.
In addition to that, always add curly braces to your `if` conditionals, even if there is no `else`. Booleans should be declared according to their Objective-C definition, and hence take `YES` or `NO` as values.
## Translations
Any category extension on UIKit, or popular libraries, should be prefixed with `ows_` to avoid collisions.
Thanks to a dedicated community of volunteer translators, Signal is now available in more than one hundred languages. We use Transifex to manage our translation efforts, not GitHub. Any suggestions, corrections, or new translations should be submitted to the [Signal localization project for iOS](https://www.transifex.com/open-whisper-systems/signal-ios/).
One note, for programmers joining us from Java or similar language communities, note that [exceptions are not commonly used for errors that may occur in normal use](http://stackoverflow.com/questions/324284/throwing-an-exception-in-objective-c-cocoa/324805#324805) so familiarize yourself with **NSError**.
### UI conventions
We prefer to use [Storyboards](https://developer.apple.com/library/ios/documentation/general/conceptual/Devpedia-CocoaApp/Storyboard.html) vs. building UI elements within the code itself. We are not at the stage to provide a .strings localizable file for translating, but the goal is to have translatable strings in a single entry point so that we can reach users in their native language wherever possible.
## Issues
## Tabs vs Spaces
Please search both open and closed issues to make sure your bug report is not a duplicate.
It's the eternal debate. We chose to adopt spaces. Please set your default Xcode configuration to 4 spaces for tabs, and 4 spaces for indentation (it's Xcode's default setting).
### The issue tracker is for bugs, not feature requests
The GitHub issue tracker is not used for feature requests, but new ideas can be submitted and discussed on the [community forum](https://community.signalusers.org/c/feature-requests). The purpose of this issue tracker is to track bugs in the iOS client. Bug reports should only be submitted for existing functionality that does not work as intended. Comments that are relevant and concise will help the developers solve issues more quickly.
![Tabs vs Spaces](http://cl.ly/TYPZ/Screen%20Shot%202014-01-26%20at%2019.02.28.png)
### Send support questions to support
You can reach support by sending an email to support@signal.org or by visiting the [Signal Support Center](https://support.signal.org/) where you can also search for existing troubleshooting articles and find answers to frequently asked questions. Please do not post support questions on the GitHub issue tracker.
If you don't agree with us, you can use the [ClangFormat Xcode plugin](https://github.com/travisjeffery/ClangFormat-Xcode) to code with your favorite indentation style!
### GitHub is not a generic discussion forum
Conversations about open bug reports belong here. However, all other discussions should take place on the [community forum](https://community.signalusers.org). You can use the community forum to discuss anything that is related to Signal or to hang out with your fellow users in the "Off Topic" category.
## Contributors
### Don't bump issues
Every time someone comments on an issue, GitHub sends an email to [hundreds of people](https://github.com/signalapp/Signal-iOS/watchers). Bumping issues with a "+1" (or asking for updates) generates a lot of unnecessary email notifications and does not help anyone solve the issue any faster. Please be respectful of everyone's time and only comment when you have new information to add.
Signal wouldnt be possible without the many open-source projects we depend on. Big shoutout to the maintainers of all the [pods](https://github.com/signalapp/Signal-iOS/blob/master/Podfile) we use!
### Open issues
The original version of Signal was developed by Twisted Oak Studios.
v1.0 development by Twisted Oak Studios:
#### If it's open, it's tracked
The developers read every issue, but high-priority bugs or features can take precedence over others. Signal is an open source project, and everyone is encouraged to play an active role in diagnosing and fixing open issues.
- Connor Bell (@connorbell)
- Craig Gidney (@strilanc)
- Matthew Jewkes (@mjewkes)
- Petar Markovich (@Waxford)
- Jazz Turner Baggs (@jazzz)
### Closed issues
The development from 1.0 to 2.0 of Signal was managed by [Christine Corbett](https://twitter.com/corbett) and [Frederic Jacobs](https://twitter.com/FredericJacobs). After the release of Signal 2.0, Christine moved on to other projects.
#### "My issue was closed without giving a reason!"
Although we do our best, writing detailed explanations for every issue can be time consuming, and the topic also might have been covered previously in other related issues.
We would like to particularly thank the following people for contributing to Signal 2.0:
- Tyler Reinhard for his work on Signal 2.0 design
- Cade (@helveticade) for his numerous UX and UI contributions
- Dylan Bourgeois for his work on helping to integrate TextSecure UI into the existing Signal project
- Joshua Lund for the amazing QA work and immensely helpful feedback provided over the months of testing
- Joyce Yan and Jack Rogers for their contributions at the Winter Break of Code
- [Abelard](http://abelard.bandcamp.com/) for the Signal ringtones and notification sounds
## Pull requests
### Smaller is better
Big changes are significantly less likely to be accepted. Large features often require protocol modifications and necessitate a staged rollout process that is coordinated across millions of users on multiple platforms (Android, iOS, and Desktop).
Try not to take on too much at once. As a first-time contributor, we recommend starting with small and simple PRs in order to become familiar with the codebase. Most of the work should go into discovering which three lines need to change rather than writing the code.
### Sign the Contributor License Agreement (CLA)
You will need to [sign our CLA](https://signal.org/cla/) before your pull request can be merged.
### Submit finished and well-tested pull requests
Please do not submit pull requests that are still a work in progress. Pull requests should be thoroughly tested and ready to merge before they are submitted.
### Merging can sometimes take a while
If your pull request follows all of the advice above but still has not been merged, this usually means that the developers haven't had time to review it yet. We understand that this might feel frustrating, and we apologize. The Signal team is still small, but [we are hiring](https://signal.org/workworkwork/).
## How can I contribute?
There are several other ways to get involved:
* Help new users learn about Signal.
* Redirect support questions to support@signal.org and the [Signal Support Center](https://support.signal.org/).
* Redirect non-bug discussions to the [community forum](https://community.signalusers.org).
* Improve documentation in the [wiki](https://github.com/signalapp/Signal-iOS/wiki).
* Join the community of volunteer translators on Transifex:
* [Android](https://www.transifex.com/projects/p/signal-android/)
* [iOS](https://www.transifex.com/open-whisper-systems/signal-ios/)
* [Desktop](https://www.transifex.com/projects/p/signal-desktop/)
* Find and mark duplicate issues.
* Try to reproduce issues and help with troubleshooting.
* Discover solutions to open issues and post any relevant findings.
* Test other people's pull requests.
* Contribute to Signal via the [Freedom of the Press Foundation's donation page](https://freedom.press/crowdfunding/signal/).
* Share Signal with your friends and family.
Signal is made for you. Thank you for your feedback and support.