Welcome! We’re glad you’re interested in contributing to WriteFreely.
For questions, help, feature requests, and general discussion, please use our forum.
For bug reports, please open a GitHub issue. See our guide on submitting bug reports.
There are many ways to contribute to WriteFreely, from code to documentation, to translations, to help in the community!
See our Contributing Guide on WriteFreely.org for ways to contribute without writing code. Otherwise, please read on.
First, you’ll want to clone the WriteFreely repo, install development dependencies, and build the application from source. Learn how to do this in our Development Setup guide.
Next, join our forum so you can discuss development with the team. Then take a look at our roadmap on Phabricator to see where the project is today and where it’s headed.
When you find something you want to work on, start a new topic on the forum or jump into an existing discussion, if there is one. The team will respond and continue the conversation there.
Lastly, before submitting any code, please sign our contributor’s agreement so we can accept your contributions. It is substantially similar to the Apache Individual Contributor License Agreement. If you’d like to know about the rationale behind this requirement, you can read more about that here.
All stable work lives on the master
branch. We merge into it only when creating a release. Releases are tagged using semantic versioning.
While developing, we primarily work from the develop
branch, creating feature branches off of it for new features and fixes. When starting a new feature or fix, you should also create a new branch off of develop
.
For fixes and modifications to existing behavior, branch names should follow a similar pattern to commit messages (see below), such as fix-post-rendering
or update-documentation
. You can optionally append a task number, e.g. fix-post-rendering-T000
.
For new features, branches can be named after the new feature, e.g. activitypub-mentions
or import-zip
.
The scope of work on each branch should be as small as possible -- one complete feature, one complete change, or one complete fix. This makes it easier for us to review and accept.
We value reliable, readable, and maintainable code over all else in our work. To help you write that kind of code, we offer a few guiding principles, as well as a few concrete guidelines.
go fmt
before committing (important!)mixedCaps
We highly value commit messages that follow established form within the project. Generally speaking, we follow the practices outlined in the Pro Git Book. A good commit message will look like the following:
Ref T000
or Closes T000
Ref #000
or Fixes #000
When in doubt, look to our existing git history for examples of good commit messages. Here are a few:
Like our GitHub issues, we aim to keep our number of open pull requests to a minimum. You can follow a few guidelines to ensure changes are merged quickly.
First, make sure your changes follow the established practices and good form outlined in this guide. This is crucial to our project, and ignoring our practices can delay otherwise important fixes.
Beyond that, we prioritize pull requests in this order:
Any pull requests that haven’t previously been discussed with the team may be extensively delayed or closed, especially if they require a wider consideration before integrating into the project. When in doubt, please reach out on the forum before submitting a pull request.