Info | ||
---|---|---|
| ||
This page is an alternative proposal regarding the guidelines for using the OFBiz JIRA instance. |
For now this is WIP.
Introduction
These guidelines have been created to help OFBiz Contributors to use JIRA effectively for the improvement of the various Apache OFBiz products (the code, the website, the documentation, etc). This document contains the best practices we advice our contributors to work with.
If you have a question regarding this page, or something can be improved, then please do not hesitate to post your question or remark to the OFBiz Community by sending an email to the OFBiz Development Mailing List.
Creating an issue
Info |
---|
In this project anyone can create an issue in our JIRA. This project project has no restrictions on who can. Anyone creating an issue is regarded as a OFBiz Contributor. |
Creating an issue in our JIRA adds to the (technical) debt of the project. Therefore, creating an issue must be done with care.
If you feel uncertain about the validity of the issue you have in mind, feel free to check with the OFBiz Community by sending an email to the OFBiz Development Mailing List. Your fellow contributors are there to help you out.
Working on an issue
While you're working on your issue(s) to get them to a successful resolution, do not hesitate to invite other OFBiz Contributors to provide insights or other kinds of feedback. It will help to bring the best (most acceptable) solution forward and grow the community.
We advise to bring as much information as possible to the issue in order to get it to a successful resolutions, whether that be in enhancing the description field or through comments. However, we caution to ensure that the comments provided to/on the issue are kept in sync with the intent of the issue's title and description. To much digression from that may lead to misunderstanding and/or scope creep. If you feel that comments provides warrants an new issue, suggest the poster of that comment to create one.
If you feel that the issue entails more effort and time than initially expected, consider splitting the issue up in sub-tasks or relating issues. It may help triggering other contributors to pitch in more.
Getting your patch
file(
sfiles) reviewed
If you have provided your patch file (sfiles) to the issue and you feel confident that the work is done, invite fellow OFBiz contributors to act as reviewers by sending a message to the OFBiz Development Mailing List.
The issue you're working on need not to be reassigned for that activity.
Should the review uncover any flaws, work or collaborate to get these resolved. Should the review uncover any new issues, we advise to create new OFBiz issues accordingly.
Getting your change(s) committed
If, after review, no obstructions - to have the patch file (sfiles) committed to the appropriate development branches branch(es) - appear to exist, we advise you to send a message to OFBiz Development Mailing List to invite a contributor with commit privileges to persist the changes in the patch file (sfiles) in into the suggested branchesbranch(es).
In order to get your contribution(s) in the form of (one or more) patch (files) committed, the issue need not be reassigned to the contributor with the commit privilege. This contributor community member is there to assist you to get the issue successfully resolved.
Closing an issue
Successful resolution
When the changes provided to issues of the type Bug, Improvement and New Feature have been committed to the appropriate branch(s) for the given product(s)/component(s), it is time to close the issue. As we have different kinds of OFBiz issues (see section 3.1), so does the resolution type differ accordingly. Please set the resolution type of the issue in accordance with following schema:
Issue type | Resolution Type | Explanation |
---|---|---|
Bug | Fixed | |
Improvement | Implemented | |
New Feature | Implemented | |
Sub-Task | To be set in accordance to the type of the parent (placeholder) issue. E.g. if the parent issue is of the type 'Bug', then the sub-task must be resolved as such. | |
Task | Completed | |
Wish | T.b.d |
Unsuccessful resolution
Should you, while working on the issue, realise that the issue doesn't exist anymore or was created under an unintentional misbelief, we advise you close the issue at the earliest convenience in accordance with following schema:
Issue type | Resolution type(s) | Explanation |
---|---|---|
Bug | ||
Improvement | ||
New Feature | ||
Sub-Task | To be set in accordance to the type of the parent (placeholder) issue. E.g. if the parent issue is of the type 'Bug', then the sub-task must be resolved as such. | |
Task | ||
Wish | T.b.d. |
Reopening a closed issue
Info |
---|
Issues that have been closed with a successful resolution should not be reopened. If such |
T.b.d.
Bug Issue
Background
A bug is generally a problem with code or data which is not functioning correctly.
Priority
As there is no obligation to contribute it is difficult - at project level - to prioritise an OFBiz Improvement issue. However, every contributor can set the priority of the issue, he is assigned to, in accordance with his schema, desire and/or conviction. Any priority set does not imply an enforceable action.
Please consider the following schema for OFBiz Improvements when setting the priority you create (as the reporter) or when you are the assignee:
Priority | Current JIRA Definition | Re: Bug Proposed Revised Definition and when to to use this priority |
---|---|---|
Blocker | Blocks development and/or testing work, production could not run | A blocking issue an issue with a released OFBiz version (or branch) that does not run, does not comply with the legal requirements of the Apache Software Foundation, is a security vulnerability to the OFBiz adopter or exposes the project to an unacceptable risk. |
Critical | Crashes, loss of data, severe memory leak | A critical issue is an issue with a released OFBiz version (or branch) that causes the system to crash, become unstable, lose data and has no workaround. A critical issue may also be one that is detrimental to the reputation of the product and/or the project. |
Major | Major loss of function | A major issue is an issue with a released OFBiz version (or branch) that has a significant impact due to loss of function and has no or limited workarounds. |
Minor | Minor loss of function or problem where easy workaround is present | A minor issue is an issue with a released OFBiz version (or branch) that has isolated minor impact. As an example: typo's in OFBiz Labels and missing OFBiz Labels can be regarded as a bug of minor priority. |
Trivial | Cosmetic problem like misspelt words or misaligned text | Don't use this for bug issues, as bugs are never trivial. |
Affected Version/s
For bug issues the 'Affected Version/s' field should be set to one (or more) releases and/or branches in accordance with the following list:
- any available release
- any available release branch
- Trunk
Setting the correct affected version(s) helps other adopters to determine how the issue impacts their OFBiz implementation or the experience of their users. It also helps other OFBiz contributors to decice where to spend their effort and time.
Fix version/s
For bugs the 'Fix Version/s' field should be set to one (or more) releases and/or branches.
Be aware that the projects reserves her rights to apply the provided patch file(s) to any other (and available or future) release or branch.
Improvement Issue
Background
An improvement is something that enhances the functionality of an existing feature in one or more products/components.
Priority
As there is no obligation to contribute it is difficult - at project level - to prioritise an OFBiz Improvement issue. However, every contributor can set the priority of the issue, he is assigned to, in accordance with his schema, desire and/or conviction. Any priority set does not imply an enforceable action.
Please consider the following schema for OFBiz Improvements when setting the priority you create (as the reporter) or when you are the assignee:
Priority | Description / Explanation |
---|---|
Blocker | Don't use this for improvement issues, as improvements can never be blocking. |
Critical | Classifying the issue with this level indicates that the issue impacts multiple products/components. Placeholder issues (issues encompassing multiple sub-tasks and/or other linked issues) can have this setting. |
Major | Classifying the issue with this level indicates that the issue impacts multiple elements within one product/component. |
Minor | Classifying the issue with this level indicates that the issue impacts a single element within one product/component. |
Trivial | Classifying the issue with this level indicates that the issue impacts a cosmetic aspect in the code within one product/component, e.g. typo's in code comments. |
Review
Patch files submitted to an issue of this type and having the priority (impact) setting Critical and Major must always be reviewed by fellow contributors before being committed to a branch. Multiple aspects must be evaluated and assessed before the commit happens, like:
- adherence to coding conventions,
- performance impact,
- security impact,
- t.b.d.
Affected Version/s
For improvement issues the affected version should be set to one (or more) releases and/or branches in accordance with the following list:
- any available release
- any available release branch
- Trunk
Setting the correct affected version(s) helps adopters to determine how the issue impacts their OFBiz implementation(s) and the experience of their users. It also helps other OFBiz contributors to decide where to spend their effort and time.
Fix Version/s
Patches of OFBiz Improvement issues will be applied to a specific Fix version, called 'Upcoming Branch'. This is to easily determine which OFBiz Improvement issues go into the next (future) development branch.
Be aware that the projects reserves her rights to apply the provided patch file(s) to any other (and available or future) release or branch.
New Feature Issue
Background
An issue of this type is about a new functionality (set) that does not already exist in any of the OFBiz products/components.
Priority
As there is no obligation to contribute it is difficult - at project level - to prioritise an OFBiz Feature issue. However, every contributor can set the priority of the issue, he is assigned to, in accordance with his schema, desire and/or conviction. Any priority set does not imply an enforceable action.
Review
Patch files submitted to an issue of this type must always be reviewed by fellow contributors before being committed to a branch. Multiple aspects must be evaluated and assessed before the commit happens, like:
- adherence to coding conventions,
- performance impact,
- security impact,
- t.b.d.
Affected Version/s
For New Feature issues the affected version need not to be set when creating the issue. However, when providing patch files this field can be used to indicate against which version the files can be applied to test against (in accordance with the schema provided below).
- any available release
- any available release branch
- Trunk
Setting the correct affected version(s) helps adopters to determine how the issue impacts their OFBiz implementation(s) and the experience of their users. It also helps other OFBiz contributors to decide where to spend their effort and time.
Fix Version/s
Patches of OFBiz New Feature issues will only be applied to a specific Fix version, called 'Upcoming Branch'. This is to easily determine which OFBiz Improvement issues go into the next (future) development branch.
Task Issue
Background
A task is an action that needs to be carried out, that does not fall under any of the other issue types. This kind of issues can be used to keep tabs on issues registered in the issue tracking solutions of other ASF Offices or Projects, or other (outside) organisations and setups.
Priority
As there is no obligation to contribute it is difficult - at project level - to prioritise an OFBiz Task issue. However, every contributor can set the priority of the issue, he is assigned to, in accordance with his schema, desire and/or conviction. Any priority set does not imply an enforceable action.
The priority of this kind of OFBiz issues should be set in accordance to the consensus within the OFBiz Community.
Affected Version/s
For now, this field should not be used.
Fix Version/s
For now, this field should not be used.
Wish Issue
Background
An issue of this type is to be used for any issue not fitting in the other types.
Priority
As there is no obligation to contribute it is difficult - at project level - to prioritise an OFBiz Wish issue. However, every contributor can set the priority of the issue, he is assigned to, in accordance with his schema, desire and/or conviction. Any priority set does not imply an enforceable action.
Please consider to explain why you (as a reporter or assignee) prioritise the issue as you did. It helps other OFBiz Contributors to understand.
Affected Version/s
For now, this field should not be used.
Fix Version/s
For now, this field should not be used.
Sub-Task Issue
Background
This task is a child of another JIRA issue.
This type will be set automatically when a new sub task is created via the 'More' menu of an existing issue.
We advise to keep sub-task issues in line with the parent (placeholder) issue. If the parent issue is of the type Improvement then the sub-task issues are to be regarded of the same type.
Priority
As there is no obligation to contribute it is difficult - at project level - to prioritise an OFBiz Improvement issue. However, every contributor can set the priority of the issue, he is assigned to, in accordance with his schema, desire and/or conviction. Any priority set does not imply an enforceable action.
Please consider to set the priority (of the sub-task) not higher that the priority of the parent (place-holder) issue. Also consider to explain why you (as a reporter or assignee) prioritise the issue as you did. It helps other OFBiz Contributors to understand.
Affected Version/s
For improvement issues the affected version should be set to one (or more) releases and/or branches in accordance with the following list:
- any available release
- any available release branch
- Trunk
Setting the correct affected version(s) helps adopters to determine how the issue impacts their OFBiz implementation(s) and the experience of their users. It also helps other OFBiz contributors to decide where to spend their effort and time.
Fix Version/s
Patches of OFBiz Improvement issues will be applied to a specific Fix version, called 'Upcoming Branch'. This is to easily determine which OFBiz Improvement issues go into the next (future) development branch.
Be aware that the projects reserves her rights to apply the provided patch file(s) to any other (and available or future) release or branch.
Missing OFBiz products/components in JIRA
If you should experience that you can't assign your issue to a particular OFBiz product or component, please post your question or remark to the OFBiz Community by sending an email to the OFBiz Development Mailing List