Contributing
Contents
- Contents
- Introduction
- Pre Knowledge
- Processes
- Internal Outreach
- External Outreach
- Code Standards
- Document Standards
- Finding Issues
- Other
Introduction
This set of guidelines is still in it's infancy, some sections may be incomplete.
Before contributing to this project, please read through this document.
You should make sure you:
- Know how the project is laid-out
- Know what the project is
- Know how the project moves
- Know that you need to contact some humans at some point
- Know who to contact
- Know what to contribute
With that in mind, here are some basic guidelines.
Pre Knowledge
Code
This repository has no code. Instead, this repository is for organizing a particular team of developers ("Team Blue"). If you want to make code contributions, make sure you are looking at the correct repository. Since we are not hosting any code (we are contributing to someone else's codebase), we will be following their guidelines and using their tools. You should familiarize yourself with whatever external project we are contributing to.
Documents
What this repository does contain a lot of is design notes, meeting notes, final documents, and other paperwork.
These are all named, sorted, handled, and stored in a particular way.
The best way to learn is to just browse through the repository itself, most folders will have a README
in them to explain what they are.
In general, you will want to pay particular attention to the DEVELOPERS
folder, as this will have specific documents on document processes.
Processes
These are general processes for how this team should conduct itself. These processes are designed specifically to help a team work better together. As an independent individual, you may not find them especially useful. In broad terms, these processes should vaguely resemble the scientific method. Again, the code processes assumes we are contributing to some external group's codebase.
Code Process
- Spend some time studying the external group's codebase
- Identify an interesting problem and take some notes on it
- Write down your ideas into an proposal-issue on the issue tracker
- Get feedback on your ideas and further refine your issue into a set of actionable code-issues
- Some people will volunteer for your issues if you have made sure to engage them in dialog, if not, return to step 4
- As you close your code-issues, reach out to the external group for submitting your patches, and consider whatever guidelines they have
- On successfully closing your issues with the external group, close your issues here as well.
Now, as you may have noticed, this is just more work to contribute to the external group, as opposed to just working with them directly. The whole point of this process is to involve the people on this team, hence why reaching out is so important.