Contributing

Helping Algid Grow

Want to help algid become a better framework? Here are some ways you can help:

• Report bugs and feature requests in our issue tracker. Please read the reporting bugs section below for details on reporting.
• Contribute bug and feature patches. See the submitting patches section below for details on creating and submitting patches.
• Join the algid hacker group. Join our developer group to share your ideas for improving algid. We are always interested to listen to ideas and review potential additions.
• Join the algid user group. Join our user group to others learn how to develop using algid.
• Triage patches submitted by other users. See the ticket triage section below for details on creating and submitting patches.

With that you can help to make algid an even better framework.

Reporting Bugs

Well written bug reports makes fixing bugs all the easier. Since it takes time to go through each issue we ask that you follow the following guidelines:

• Do search through the wiki to see if there is a section dealing with your issue.
• Do search the issue tracker to see if it's already been fixed.
• Do search the algid users group for similar troubles.
• Do ask on the algid users group if you are not sure it is a bug.
• Do write complete, reproducible, detailed bug reports. Include any relevant information including code snippets, test cases, debugging information, etc. The more we know and are able to reproduce the problem the easier it is to fix.
• Don't use the issue tracker for support questions. Ask your questions to the algid users group.
• Don't use the issue tracker to suggest large scale changes. We like to discuss large changes to the framework on the algid hacker group.
• Don't reopen issues that have been marked WontFix as the decision has been made. Talk to the algid hacker group if you have more questions about the issue.
• Don't use the ticket tracker for lengthy discussion. Please bring the discussion to the algid hacker group and keep the issue tracker clean.
• Don't post to the groups just to report you have filed a bug unless the discussion was already started and you are letting the group know it has been filed.

Reporting Security Issues

Report security issues to [[algid-security@googlegroups.com]]. This is a private group only open to long-time, highly trusted, core developers and the archives are not publicly readable.

In the event of a confirmed vulnerability in algid itself, we will take the following actions:

• Acknowledge to the reporter that we’ve received the report and that a fix is forthcoming. We’ll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
• Halt all other development as long as is needed to develop a fix, including patches against the current and previous release.
• Determine a go-public date for announcing the vulnerability and the fix. To try to mitigate a possible “arms race” between those applying the patch and those trying to exploit the hole, we will not announce security problems immediately.
• Pre-notify everyone we know to be running the affected version(s) of Django. We will send these notifications through private e-mail which will include documentation of the vulnerability, links to the relevant releas(es), and a request to keep the vulnerability confidential until the official go-public date.
• Publicly announce the vulnerability and the fix on the pre-determined go-public date. This will probably mean a new release of algid.

Submitting Patches

Patches to existing issues and new features are greatly appreciated and encouraged. Issues that have a patch will be much more likely to be fixed quickly compared to those without patches.

Do not submit large patches out of the blue, they will be rejected. Any large changes need to be discussed on the algid hacker group before being accepted and, preferably, before being programmed.

Please don't put your name in the code you contribute. Our policy is to keep contributors' names in the Authors page of the wiki -- not scattered throughout the codebase itself. Feel free to include a change to the wiki file in your documentation patches if you make more than a single trivial change.

Issue Patch Style

• Make sure existing and new unit tests run correctly after the patch.
• Make sure that your patch follows our coding styles.
• Submit patches from git format-patch or by creating a pull request.
• The code to fix the problem or add a feature is essential, but not necessarily complete. A good patch should also contain unit tests to test that the bug fix or feature works as expected and will continue to work with future changes.

Documentation Patch Style

• Make sure that your patch follows the GitHub Flavored Markdown.
• Submit patches from git format-patch or by creating a pull request.

Ticket Triage

Since not all patches are created equally it is necessary to review the patches and commits to the repository.

If you have time and opportunity to test out patchs that have been submitted and have some feedback please update the issue with your comments or additional patches needed to fix the problem.

Submitting and Maintaining Translations

The more translations available for algid plugins the easier it is to create locale friendly applications. If you have skills with languages please see the I18N page for more information on translating algid plugins.