GitHub Issue Tracker
printer friendly
BHL-Europe > BHLE_WP3 > GitHub Issue Tracker_General Guidelines for Developers
GitHub Issue Tracker – Guidelines for Developers.
Section 1. Introduction:
The project is now in its development phase in terms of the portal and hence all features
outlined in the Catalogue of Requirements have been migrated and added as Issues in the
GitHub Issue tracker.
From henceforth we will be using the Issue Tracker until the development process
reaches maintenance mode i.e. when the development phase has achieved all its goals and
is generally considered to be complete and bug-free.
About the GitHub Issue Tracker:
All development activities in a project can be tracked in an Issue tracking database.
This project is using the GitHub Issue Tracker which is a more generalised tool for
tracking different kinds of activities/issues.
Types of Issues developers will be dealing with have been labelled as follows:-
1. Bug (Defect): a problem with an existing feature that has not been developed to
specification or does not work as designed.
2. Feature: an addition to the software to add a piece of functionality that does not
yet exist.
3. Feature Request (Enhancement): an improvement to an existing feature or new
feature request.
4. Project Tasks: This refers to all task activities transferred from the Scrum
Backlog i.e. tasks in support of ongoing development work, Implementation of
OAIS modules, GUID work etc.
Priority Labelling:-
The Priority has been determined to help developers prioritise the work according to the
level of Importance:-
1. Critical: Must Have for a specified release
2. Minor: Should Have for a specified release
3. Normal: Nice to Have for a specified release
Additional labels:
Additional labels have been added in order to provide further classification and clarity for
developers when filtering issues. These include: - Web Services, GRIB and also dates to
highlight the regular releases that we have planned: - Aug 2011, Nov 2011, March 2012
etc.
Milestones:
Once the Issue has been created, they should be associated with a milestone indicating
when the work on a particular issue must be completed by. For example:-
The Development core release: - this is our first Major Milestone, followed by the
November sub Release Milestone etc.
Section.2 Important Guidelines and general housekeeping rules for developers when using the Issue
Tracker.
1. Feature Requests: In case an important feature appears to be missing, email the description to Jana/Lola for assessment, if it's agreed as a new required feature it will be added with the 'Feature' label by Jana or Lola.
2. New Bugs: Please don’t use the ‘Feature’ label for any issues encountered during
development (use “Bugs”) add the feature number in the heading of the bug
together with a bug name; comment in the feature and the bug with the reference
number e.g. #1 (this produces a link to the respective feature or bug); assign to
milestone! (same as for feature). Finally, assign them to either Jiri, Jana or Lola.
3. Amendments: Please do not amend feature descriptions in the issue tracker (add
as comments only under the specific feature). This will be documented in the
catalogue of requirements by Jana, who will then make the changes in the issue
tracker accordingly.
4. Open Status: All developers should now be concentrating on Open features and bugs that
have been assigned to the “Development Core release” milestone.
Questions on Issues: If you have a question related to a particular issue, please add the question as a comment and assign the issue back to Lola/Chris where we will answer.
5. All development work by developers including bug fixes should be carried out on
the code that you install on your machines.
6. Closed status: Once the Issue has been completed by the developer please ensure that the code changes are committed to github, and that the code has been deployed via jenkins to the integration server (bhl-mandible).
Test that the update works there, then update the status by closing the Issue in the “Development Core Release milestone” and
assign it to the QA Manager (Jiri Frank). This is important in order for the QA
team to identify features/bugs that are ready for testing asap.
7. Always use the side bar to filter Issues by their respective labels and milestones.
8. All testing documentation will be uploaded on the Wiki under “Evaluation &
Testing.
Functional+Testing
N.B. Please contact a member of the QA team (Jiri Frank/Jana Hoffmann) or Lola Obajuluwa if
you have any queries.
