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`](../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](https://en.wikipedia.org/wiki/Scientific_method).
Again, the code processes assumes we are contributing to some external group's codebase.
### Code Process
1. Spend some time studying the external group's codebase
2. Identify an interesting problem and take some notes on it
3. Write down your ideas into an **proposal-issue** on the [issue tracker](https://gitlab.cci.drexel.edu/courseeval/team-blue/-/issues)
4. Get feedback on your ideas and further refine your issue into a set of actionable **code-issues**
5. Some people will volunteer for your issues if you have made sure to engage them in dialog, if not, return to step 4
6. As you close your **code-issues**, reach out to the external group for submitting your patches, and consider whatever guidelines they have
7. 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.
### Document Process
1. Figure out what it is you are trying to say, how you want to say it, and who you want to have hear it
- If you think there is an issue with how the team is behaving, create a new **team-issue**
- If you want to propose some new feature or way of working, create a new **improvement-issue**
- If you want to have an extended conversation, ping the team on [Discord](https://discord.gg/QKBxxSS9) and pick a date to meet up
- If you want to quickly raise a point or ask a question, post it to us on [Discord](https://discord.gg/QKBxxSS9)
- If you are afraid of asking everyone, message Peter ([peter201943#8017](https://discord.com/users/312363766954065930)) privately
- If you feel the team is acting inappropriately, [send an email to the course instructor](mailto:hislopg@drexel.edu)
- Everything else is a "formal document process" covered under [Document Standards](#document-standards) or in the [`DEVELOPERS`](../developers/) folder
This is important because posting something to the wrong channel can lead to it being ignored.
2. Check for any templates
Often, a template will exist, especially for remedial items (such as discussions, decisions, and issues).
The point of the templates is save you time.
3. Write your document.
If this is your first time writing a particular document, look at some past examples.
For certain documents, they will have some special rules written out under the [Document Standards](#document-standards) or in the [`DEVELOPERS`](../developers/) folder.
Since we are using [Git](https://en.wikipedia.org/wiki/Git) for all of the documents on this repo, do not feel bad about submitting incomplete or incorrecte documents!
However, if you *abandon* your document, we will find you 😈.
(Kidding aside, please don't just dump a bunch of documents and run).
4. Get feedback on your documents.
In the spirit of democracy, try to involve the other members of the team when you can.
Now, with the above, the use of Discord and Issues is strongly encouraged. If you are not familiar with how to use Discord, you should take some time to learn some Discord etiquette.
[A Suggestion for Discord Channel Etiquette](https://medium.com/@wysiwyg.comment/a-suggestion-for-discord-channel-etiquette-2b4d1a20ea0d) and
[the Discord Subreddit](https://www.reddit.com/r/discordapp/) can give you some tips on using Discord.
With regards to issues, it is very important to do three things:
1. Give your issues good names
More than anything else, a good name can help everyone else on the team figure out what your issue is.
It's often the first or only thing someone sees, and if it is not named well, the right person may skip over it.
Give your issue a descript, but not overly verbose name.
2. Tag your issues appropriately
Specifically, make sure to use all three *kinds* of labels (`Status`, `Task`, `Topic`).
Each of these groups of labels helps the team to find your issue better.
[Each label also has a short description](https://gitlab.cci.drexel.edu/courseeval/team-blue/-/labels).
3. Use the issue templates
These templates save everyone time trying to both read through an issue and having to ask questions later.
A few different kinds of templates should be available, and if you do not like any of them, feel free to edit one.
