How to Use Issues in Arctos
The Issue Process: How to Make Arctos Work for You
Improvements to Arctos can come from any Arctos user. Suggested improvements can include simple coding bug fixes, the addition/deletion of data fields or menu items, new forms/buttons/functions to streamline collection processes - anything that will help Arctos users better manage and access Arctos data/specimens/objects.
Changes to Arctos are submitted, discussed, prioritized, and tracked to completion using Issues in GitHub. Once an Issue is created it will be reviewed by the Arctos Working Group. Issues that do not require a discussion (bug fixes or broken forms/functions) will be resolved by Arctos programmers. An Issue requiring discussion will be considered by the Arctos Workinig Group, the Issue author, and other interested users - Issues and discussions are open to all. The discussion of an Issue occurs within the comments of the Issue.
To file an Issue you will need to create a username and login to Github. Login to GitHub and use this link https://github.com/ArctosDB/arctos/issues/ to access Arctos Issues. Search existing Issues to be certain your Issue does not already exist.
If a similar Issue already exists you can comment on it. If you want to create a new Issue...
When filing an issue that you don't intend to fix immediately, leave Assignee blank. It's fair game for everyone else to ignore "assigned" issues.
Assign one of the following Milestones to every Issue. Adding Milestones to Issues lacking them should be a priority for everyone.
- Needs Discussion: The path to implementation is unclear and requires discussion by involved parties, the Advisory Committee, and/or the Arctos Group.
- Next Task: The development needed is well-defined and accepted; just needs code written. Developers are unlikely to look at anything else, so please open or participate in discussions to help get the Issues important to you categorized here. Everything under this Milestone should have a Priority label; please add one if necessary.
- Active Development: Code is being written. Use this as development begins; make sure an Assignee is listed.
- Wish List: Major development, or development requiring major funding.
- Wont Fix: The Issue has closed without action. Leave verbose comments when using this.
Please mark all resolved Issues as Closed.
Note that the some of the functionality built into Labels at Google Code has been replaced by Milestones.
- Priority-Critical: Issue is causing major problems; corrupting data, crashing servers, etc.
- Priority-High: Issue is actively preventing progress.
- Priority-Normal: Standard Issue
- Priority-Low: Needs fixed/implemented/discussed, eventually.
- Type-Bug: Issue is related to defective existing code. Example: The "save" button does not.
- Type-Enhancement: Issue is a request for additional or improved functionality. Example: An idea for improving efficiency; a new type of data.
- Type-Performance: Issue is a request for tuning. Example: An important query times out.
- Type-Data: Issue refers to data, not application. Example: A spelling error in a code table is found.
- Assign Function-Thing labels to help categorize Issues
Please note: These links are listed roughly in the order in which developers will encounter them. If your issues are not where you want them to be, add or change metadata.
- Open "Active Development" Issues are those which we're working on right now. This should be assigned only by the person who intends to address the Issue.
- Open "Next Task" Issues are those which are ready for implementation. GitHub has no voting system, but please leave a comment to help us prioritize.
- Open "Needs Discussion" Issues are those which sufficient information to proceed is not available. Please start (or join) a discussion (with the Advisory Committee or Arctos Group), and leave a link to the discussion in the comments.
- Open WishList Issues are those which, at the time of last evaluation, we don't have resources to develop.
- Open uncategorized Issues require a Milestone; please assign one.