Overview

Ticket state flow:

new -> open -> needs_ack -> acked -> proposed -> candidate -> resolved

• [ new ] - No-one has stated they have started working on this issue yet.
• [ open ] - Someone has taken responsibility for working on this issue and has started work.
• [ needs_ack ] - The developer working on the issue has an update that needs peer review before being introduced into the source repository.
• [ acked ] - Someone has looked at the solution and acknowledges it as worthwhile to include.
• [ proposed ] - The developer's update looks reasonable and is ready for wider testing. The update can be replaced by a better update, altered, backed out, etc... It is not expected to be stable at this point, but is provided so it can be tested and enhanced.
• [ candidate ] - The update seems like a good solution, is stable, and no-one seems to have reasonable objections to including it in the project.
• [ resolved ] - The update is now included in the master branch and will be a part of the next tagged release.
• [ hold ] & [ invalid ] - have their general meanings and will be commented when the state is changed.

Branch flow and meaning

pu -> next -> master

• [ pu ] - The proposed update has been acknowledged as reasonable and needs testing and community feedback.
• [ next ] - The update has tested OK and should be included in an upcoming release, but still needs more community feedback and usage.
• [ master ] - The update will be a part of the next release and the issue is considered resolved.

Flow Detail

All tickets initially have a state of 'new'.

Ticket Creation.

Prior to opening a ticket you are invited to visit the #Notepad++ IRC channel on Freenode.
Perhaps the issue isn't really an issue, or people in the channel can give details on who to assign the ticket to and what milestone to use.

Some points to remember when creating a ticket:

• You will need to be signed in to your Lighthouse account to create a ticket.
• Please use an informative subject.
• Try to give as many details in the body as possible.
• Assign the ticket to 'git(at nppcommunity)' unless you specifically know who to assign it to.
• Don't bother assigning the Milestone, it will be adjusted when someone takes ownership of the ticket.
• Add some descriptive tags.

After creating your ticket it is mainly up to the development community to get the rest done. However your continued input is important so please monitor your ticket's status.

Tickets move from 'new' to 'open' when someone decides to work on it and take ownership.

Taking Ownership.

The person working on the ticket will set the state to open and take responsibility for the ticket. This is usually done before starting to work on the update so other people don't duplicate effort, so if you see your ticket as open it means someone is interested in taking responsibility for working on it and not that they are.

Questions and concerns should be posted in public to the ticket discussion instead of directly via email.

The person working on the ticket may code in private with no visible activity until it is ready for some basic peer review. Please be patient.

Sometimes this step can take a bit of time. The more detailed the ticket is the more helpful you are being to the person who tries to help by working on it. You may see a ticket change from open back to new if the person realizes they aren't the person for the job. Sometimes the person that opened it will research and find that it is actually invalid and will comment as to why when changing the state.

Tickets move from 'open' to 'needs_ack' when the update is ready for basic peer review.

Getting Acknowledgment.

It is extremely important to try to include steps to reproduce the issue because when the person working on the issue believes they have a working solution they will ask for someone to acknowledge that their update meets some certain standards. The most important of which is that the update actually fixes your issue.

Tickets move from 'needs_ack' to 'acked' after someone gives it a sanity check.

Giving Acknowledgment

Acknowledgment of someone's code is just a way of saying "It looks good to me, and sounds reasonable.", it is not meant to be an intensive scrutiny.

When giving an acknowledgment an update is checked to ensure that it:

• doesn't break any existing tests.
• is well written.
• is limited to the issue being fixed.
• actually fixes the issue.

If the fix for your issue is at this state just sit back and relax because there is still more to do.

Tickets move from 'acked' to 'proposed' when ready for a wider more in-depth review.

Proposed Updates.

Tickets with a state of 'acked' are merged into the main repositories pu branch and graduate to proposed where they get scrutinized in detail. Other developers in the community will make suggestions or offer their own changes and updates.

While at this stage the update is checked to ensure that it:

• includes tests to ensure the fix doesn't break again in the future.
• builds on each target platform in each of the configurations.
• has any needed documentation.

This step can go round and round sometimes. While getting an update into the project is important it is also important that it be maintainable in the future. Sometimes the person who took responsibility initially will just present a poor solution and not follow through and it may be awhile before someone picks it up again.

If your ticket is in this state and you don't see any activity on it then please post a message to the ticket discussion.

Tickets move from 'proposed' to 'candidate' when ready for community feedback.

Candidacy.

Tickets with a state of proposed graduate to candidate when the community agrees it is ready.

When the proposed update looks to be ready a milestone will be set for inclusion into a release and it will be merged into the next branch of our repository.

The main purpose of this stage is to get wider community coverage of the proposed update before exposing all users to it. Possibly revealing hidden problems, or getting ideas from someone else on how to make it even better before releasing it. Candidacy will appear crossed off in the LighthouseApp ticket monitor but not counted as resolved since it can still be 'undone' if a problem is found.

When the proposed update to your issue reaches this stage you can be pretty assured the fix will work and not cause problems and by looking at the milestone you can get a good idea of when it will be released. Unless someone finds something wrong there is nothing left for you to do.

Tickets move from 'candidate' to 'resolved' when ready and tagged for a release.

Resolution.

Tickets with a state of candidate stay on the next branch until their milestone is reached and then become resolved.

By the time an update becomes a candidate the issues with it have been found and resolved, so there isn't really much left to between that point and when it becomes resolved except to wait for the milestone and hope other developers and users are using it. Developers are encouraged to use the next branch for daily use to help make sure candidates are worthwhile.

When the milestone is reached the update will be merged into the master branch and the ticket will be marked as resolved. The only thing left for anyone to do is use it and be happy.

Note:

Sometimes these steps can go very quickly and portions of the flow will be skipped because the update is obvious and trivial. This flow is not written in stone and is not meant to be followed pedantically. Rather it serves as an assurance the we truly are thinking about quality.