Contributing Source Code to OpenPetra.org: Difference between revisions
| Line 3: | Line 3: | ||
We use Mantis for tracking of those things. It can be found here: http://tracker.openpetra.org<br /> | We use Mantis for tracking of those things. It can be found here: http://tracker.openpetra.org<br /> | ||
Everyone can report issues (we will revise that if the spam becomes too much...). | Everyone can report issues (we will revise that if the spam becomes too much...).<br> | ||
When you file bugs please make sure that you've selected the correct sub-project (i.e. Partner Module, Finance Module,...)<br> | |||
before entering any data. Your choice of topics for the category of that bug will then be limited to a few items ,<br> | |||
that will help us in classifying and assigning bugs and features. | |||
===Workflow of bugs and features in Mantis bug tracker === | ===Workflow of bugs and features in Mantis bug tracker === | ||
| Line 34: | Line 37: | ||
This is done by “move issue” in Mantis. There are subprojects provided for testing related to each of the modules.<br> | This is done by “move issue” in Mantis. There are subprojects provided for testing related to each of the modules.<br> | ||
Moving the feature to one of these subprojects will make it obvious that this issue is ready for testing. <br> | Moving the feature to one of these subprojects will make it obvious that this issue is ready for testing. <br> | ||
If the test fails, the issue will be reopened which means the status will be set to “feedback”. <br> | Only features in status "resolved" are ready to be tested.<br> | ||
If the test fails, the issue will have to be reopened which means the status will be set to “feedback”. <br> | |||
There might be either know or new bugs related to this feature. If so, these relationships should be made known in Mantis, too.<br> | |||
That way the feature can only be closed if all its children are closed as well. This makes it possible to track the completeness<br> | |||
of a feature. The bugfixes should be tested first before the complete feature is marked as resolved again and a final test is done.<br> | |||
The feature remains in the test queue. Once the issue has been successfully tested, it is set to closed<br> | The feature remains in the test queue. Once the issue has been successfully tested, it is set to closed<br> | ||
and moved back to its original queue. The original queue can be found in the history of this feature. | and moved back to its original queue. The original queue can be found in the history of this feature.<br> | ||
==Questions and Discussions== | ==Questions and Discussions== | ||
Revision as of 14:01, 13 November 2012
Tracking of Bugs and Things to do
We are managing the projects, todo lists, feature requests, and bugs all in one place, also called a Tracker.
We use Mantis for tracking of those things. It can be found here: http://tracker.openpetra.org
Everyone can report issues (we will revise that if the spam becomes too much...).
When you file bugs please make sure that you've selected the correct sub-project (i.e. Partner Module, Finance Module,...)
before entering any data. Your choice of topics for the category of that bug will then be limited to a few items ,
that will help us in classifying and assigning bugs and features.
Workflow of bugs and features in Mantis bug tracker
Mantis provides the following status codes to keep track of a bug or a feature:
New, feedback, acknowledged, confirmed, assigned, resolved, closed.
The possible values for the next status are shown in the diagram below.
- current status: possible next status codes
- New: feedback, acknowledged, confirmed, assigned, resolved, closed
- Feedback: acknowledged, confirmed, assigned, resolved, closed
- Acknowledged: feedback, confirmed, assigned, resolved, closed.
- Confirmed: feedback, assigned, resolved, closed
- Assigned: feedback, resolved, closed
- Resolved: feedback(reopened), assigned, closed
- Closed: feedback(reopened), assigned, resolved(retest)
Bugs that have been resolved should be assigned to the person who reported this bug.
This person can then make sure that the fix is providing the desired functionality.
If this person does not have the skills or equipment to fully test the bugfix,
the bug needs to be passed on to a qualified person within the OpenPetra team,
who then will consult specialists from the business departments if needed.
The severity of a bug can be set to “feature” declaring it as a feature rather than a bug.
We plan to over the time enter all of the major project plan tasks as features into Mantis.
These features will have the field ProjectPlanID set to its corresponding ID from the main project plan.
If an issue is classified as a feature and has been given a ProjectPlanID, a special workflow applies .
Once the feature has reached the status resolved, it should then be moved to a different queue for testing.
This is done by “move issue” in Mantis. There are subprojects provided for testing related to each of the modules.
Moving the feature to one of these subprojects will make it obvious that this issue is ready for testing.
Only features in status "resolved" are ready to be tested.
If the test fails, the issue will have to be reopened which means the status will be set to “feedback”.
There might be either know or new bugs related to this feature. If so, these relationships should be made known in Mantis, too.
That way the feature can only be closed if all its children are closed as well. This makes it possible to track the completeness
of a feature. The bugfixes should be tested first before the complete feature is marked as resolved again and a final test is done.
The feature remains in the test queue. Once the issue has been successfully tested, it is set to closed
and moved back to its original queue. The original queue can be found in the history of this feature.
Questions and Discussions
For questions and discussions there are two places where this should happen:
- Questions and discussions which should be trackable over time and might lateron shed light on how decisions were made in the project:
- Those discussions should happen in the Forum. It can be found here: Developer Forum
- Questions and discussions which are about short-lived things or problems and where it isn't necessary to have a record of:
- Those should happen on our IRC Channel. It can be found on irc.freenode.net in room #OpenPetra
Documentation
- Technical details of an implementation in OpenPetra should always be documented in this OpenPetra wiki.
- Do not use documents (of any file format) for documentation of technical details of an implementation in OpenPetra, because
- the wiki should be the single central source of information about OpenPetra
- documents in various file formats don't usually have a change history, but the wiki keeps track of the change history
- documents outside the wiki might become forgotten on the local machine of a developer (or on a network drive) and no-one else will have (easy) access to them
Bazaar Source Code Repository and Patches
- 3 of the Core developers have write access to the Bazaar code repository of OpenPetra hosted at Launchpad (lp:openpetraorg).
- New developers should ask for a mentor. See Submitting patches and features for more information.
- Occasional developers need to
- check out the Bazaar repository from lp:openpetraorg
- or even better create a branch on Launchpad for themselves for the change. Add a patch to the bug tracker record at http://tracker.openpetra.org/ or add the link to the bazaar branch at http://launchpad.net/
Copyright of Contributions
We need to still discuss how we deal with the copyright of contributions. See also the discussion on this blog about copyright assignment.
Please let us know what you would prefer! OM is a charity, and it might be a good copyright holder to make relicensing easier. But if that is a big problem for you, please let us know, and we can discuss it.