Creating bug reports, adding your work to the project, and other subjects

[samiam95124]

Guide to:

• Reporting bugs.
• Volunteering your work on the project.
• Guide to the issues section.

All bug reports, comments, feature requests, help with the project, etc. are welcome. This is a brief guide to these issues (pun intended).

Reporting an issue

If you have found a bug or think you have, feel free to create an issue concerning it. Please include:

• What version of the code you found it in. Versions ending with "x" are so called "tip" versions, created from the archive directly.
• What steps you did to reproduce it.
• (ideally) a short code example that causes the bug.

Not sure its a bug? Want to discuss a feature? That's ok, just put it into the discussions forum. If I feel that a issue belongs in discussions, or vice versa, I will move it.

Want to contribute to the project?

There are many tasks, large and small, that need doing. Jump in! Find a ticket from the issues section that you want to work on and do it. When you are ready, file a pull request.

What do the importance/difficulty numbers mean on issues (like 3/5)?

The numbers are importance divided by difficulty, on a 1-10 scale. Thus 5/5 is medium importance, medium difficulty. 1/10 means not very important, but very hard to do. 10/1 means very important, but easy. Of course they are all subjective.

Taking ownership of an issue.

If an issue is not assigned, you can ask to take ownership of it. This will show others that someone is working on it.

Filing a pull request for work done (a code review)

A pull request gets you a code branch, and that must pass a code review to merge it. The requirements before a merge can completed are basically:

1. You read the code and found out the workings of it. Again. And again. And again. Scotty's rule: you can't fix code you don't understand.
2. Does your code match the style of the existing code? Everyone has a style. What is important here is that it looks like the existing code. If someone is reading your change, would they be unable to find your code if they didn't know were it was? Blend in.
3. You ran a regression. Study how regressions work. The %100 passing regression report should be in your branch.

Start with a simple fix, then move on to more complex fixes.