Galileo

This is a feature rich map voting plugin for AMX Mod X. It's intended to be used in place of any other map choosing plugin. See its complete description at AlliedModders' Forum:

1. https://forums.alliedmods.net/showthread.php?t=273019

Contributing

You are welcome. To start contributing to this plugin just:

1. Learn how to use GitHub.
2. Fork it on GitHub. See here how to fork on GitHub.
3. Checkout on the develop branch.
4. To read the Contributing Guidelines.
5. To see the Issues List. The best way to start it is first fixing one trivial issue and to perform its pull request and to see how it goes.
6. To see recent commits on: https://github.com/evandrocoan/Galileo/commits/master, as: https://github.com/evandrocoan/Galileo/commit/f386a49c6e07f4a4d52375a0a1d3607734e5f60d.
7. To open and to comment on issues at the Issues List.
8. And to perform pull requests.

Galileo Bug and Issue Tracker

The issue list

Head straight to https://github.com/evandrocoan/Galileo/issues for a list of all issues or click Issues in the navigation bar on the almost-top.

Use Github's reactions feature to vote on issues. Future "+1" comments with no further content will be deleted without notice.

Issues types:

1. S: blocker are the bugs we need to fix immediately. These are the bugs that will prevent the product from working if it were released in that state.
2. S: critical issues are bugs, but there is typically a workaround or a quick fix that can be applied post-release.
3. S: major issues have a workaround and can be put off without impacting the functionality of the application.
4. S: minor issues are small bugs/issues which require a small or real complex/big code changes to be fixed.
5. S: trivial issues are usually reserved for enhancements as "nice to haves" or bugs which require almost zero code changes to be fixed.

How do you define the severity (critical/high/low etc) of bugs?

Prefixes used around the Issues

1. The prefix S: , is supposed to mean the Issue's Severity.
2. The prefix T: , is supposed to mean the Issue's Type.
3. The prefix R: , is supposed to mean the Issue's Resolution.

Before creating a new issue

• Search for the issue here to check if it was already reported. You may use labels for filtering the issue list by clicking any of these related to the problem you want to report or request.

Filing a bug

1. Start with a descriptive but concise subject that quickly and uniquely identifies the problem.

• Write a summary of the problem in a few lines, giving an idea of what the issue is about.

• Then, describe the bug with all the information you can give.

  Also keep in mind to clearly separate fact from speculation.

• Try to find a way to reproduce the problem and write down precise steps. It might be useful to include a code example for this.

• Workarounds or other related tips on how to avoid the issue are welcome.

We won't slaughter you if you can't fulfill all of these steps, but prepare to answer a few questions if we think we're lacking information.

If you want to be really good at reporting bugs, you can also read these guidelines for bugzilla bugs:

1. Bugzilla – Bug Writing Guidelines
2. Bugzilla User Guide- Reporting a New Bug
3. Sourceware Bugzilla – Bug Writing Guidelines
4. Mozilla Software - Bug Writing Guidelines

Filing an enhancement or a feature request

1. Start with a descriptive but concise subject that quickly and uniquely identifies the issue.

• Explain briefly what the enhancement is and why you think it would be useful.
• Provide any other necessary or useful information regarding your issue, such as (code) examples or related links.

Note: "enhancements" are modifications to existing behavior as opposed to something entirely new.