Welcome to Elgg's documentation
This is the place to find documentation on all aspects of Elgg. If you would like to contribute your own documentation please do; we want this to be a real community effort!
Ticket Triage
From Elgg Documentation
This page lists guidelines and conventions used within the Elgg project for triage of tickets. Here is a page with various reports and lists of tickets
Currently tickets are only being triaged by developers, but this may change in the future. Ticket triage involves the sorting of tickets to evaluate if they are valid, if the bug is reproducible, if the patch is of good quality, if it isn't a duplicate, etc.
Contents |
[edit] How to Submit a Ticket
The first step (I think) is to go to [1] and submit your password at the bottom of the page. This may not be necessary.
After that login. Even if you are logged in to elgg.org, you will need to log in again - this time to the trac system. Click on the login link below the search box.
Now a "New Ticket" link will appear in the trac menu.
[edit] How to help
As mentioned earlier, a number of tickets haven't been classified yet and if you have some knowledge of Elgg you will be able to detect duplicate tickets, or can ask for clarifying a problem if it has been poorly described in the ticket.
[edit] Accepted Tickets
Tickets start out their life with status = new (not assigned to anybody) and not being "accepted" (not yet reviewed). The first thing that should happen is that a ticket is accepted. This means that the issue is reproducible, is not a duplicate and has a chance of being resolved at some point.
[edit] Assigned Tickets, Owners and Patches
As soon as possible, people should assign tickets to themselves or other people which they know are could be responsible for resolving it.
This list of not yet assigned tickets should be as empty as possible.
Helping out with one (or more) of these tickets is one of the best ways to help Elgg! For help on our conventions, terminology and keywords, see our Contributing code page. Here is a list of accepted tickets that may need patches
[edit] Milestones
Milestones are treated as release versions. When triaging, if a ticket is valid it will get attached to a milestone. Whether it will be the first next version or a later version will depend on the severity of the issue (blocker, critical, major, normal, minor, trivial) and the tie required for the fix (remember that all developers are volunteers with limited time), and how it relates to the current Roadmap.
[edit] Status and resolution
fixed is used when the resolution of the ticket can be linked to some change in the repository, a code change, a primary documentation fix, a contribution script added, etc. For ticket type task, fixed is used even if there was no trackable change in the repository/documentation.
worksforme the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way
wontfix the problem reported is not really Elgg's problem; the requested feature won't be implemented because we don't think it fits in the scope of the core of Elgg, or the feature is, or can be implemented as a plugin.
- Note: In some cases however, we let the issue open even if the cause of the issue is not directly Elgg's fault, so that workarounds and user experience can be collected.
- Note: If an API change is required to get a feature to work (that is intended to be implemented as a plugin), then a new ticket could be opened with the requested API changes. If it's not very clear what that change should be, it is preferable to keep the request for change next to the use case (i.e. keep that ticket opened for the purpose of the API change).
invalid the ticket was a test ticket
duplicate there's already another ticket about the same issue
- If marking as `duplicate`, include referring ticket number in both duplicate and duplicated tickets.
- In duplicate ticket: This ticket is duplicate of #1234
- In original request: #2345 has been marked as duplicate of this ticket
- We usually let open the ticket which contains the most up-to-the-point discussion about the issue, the one which contains an appropriate patch, or other than that, the oldest ticket.
And also, don't close or reopen a ticket without a reason.
[edit] Keywords
- accepted
This ticket was reproducible, is not a duplicate and is ready to assign to somebody.
- needinfo
waiting on information from the reporter
- verify
the ticket looks to be a valid bug report, but it would be worth that someone actually reproduces it, mainly because the person doing the triage can't reproduce it himself for some reason (different platform / browser / database, etc.)
- consider
interesting tickets, mainly for enhancements requests, that are worth to consider in the scope of a given milestone, but for which there's no commitment yet
- tobedeleted
"noise" tickets that could eventually be safely deleted one day
- helpwanted
tickets which are looking for contributors
- review
peer review requested
- documentation
things that need to be better documented
