#Contributing to Orion
Thank you for your interest in Orion. Please read the information on this page to understand how the project works and how you might contribute.
NOTE: Orion is in the process of transitioning development from Eclipse.org to github.com. As a result, information about the probject can be found in both places.
Information regarding source code management, builds, and more.
The code conventions used in Orion:
#Contributor License Agreement
Before your contribution can be accepted by the project, you need to create and electronically sign the Eclipse Foundation Contributor License Agreement (CLA):
Be sure to use the same email address in your Eclipse account that you intend to use when you commit to Git.
Contact the project developers via:
#Searching for bugs
This project uses the GitHub issue tracker as our primary bug system. If you did not a find a related in GitHub, a quick check should also be done in Bugzilla, as there may have been a bug filed there, prior to our move to use GitHub. Note that Bugzilla is no longer being used by this project.
#Opening a New Bug
So you found a problem with Orion, or have a great idea for a killer feature. Great! All you have to do is open a new issue, following the simple steps below:
#### Environment Orion Version: XX Browser: YY Operating System: ZZ #### Steps 1. Invoke File->New ... 1. Click on ... 1. BUG: XXX is not selected, but should be ... #### Notes ... please attach a screen shot or console log rather than a long description ...
If instead of a bug, you are want to propose a new feature for Orion, simply copy the template below into your new issue instead:
#### Environment Orion Version: XX Browser: YY Operating System: ZZ #### New Feature
So now you have a new issue created, what next?
The bug will move through the bug states until it is closed. Anyone is free to add comments, proposed fix ideas and carry on civilized discussion on any issue regardless of its state.
You have opened a new bug (thank you!) or you are interested to participating on an existing one (again, thank you). What do all of the tags and statse of the bug mean? Should you change or set any of them?
To answer those questions (and more), lets first take a look at the tags and what they mean.
##Bug Tags As a bug moves through its states, certain tags will be either added or removed to help committers understand the state of the bug and to help committers (or anyone else) query the bugs for particular ones.
Let's start by looking at the component tags. These tags represent a sub-area of Orion, for example, the tag
The table below describes the componet tags, with a brief description of the area the are meant for.
|Documentation for Orion|
|The Orion editor|
|Build scripts and tools for Orion|
The next set of tags describe the state of the bug. As a bug moves along its lifcycle, additional tags will be added and removed as needed.
The state tags are as follows:
|If a committer has looked at the bug, checking that all of the required information is present, this tag will be set. This tag means that the bug has been filed correctly, not that it is valid, or that someone is working on it. IMPORTANT: Bugs that do not have enough information will be closed (but can be reopened when the information is provided -- don't worry, nobody is mad at you!).|
|If the bug is mostly complete, but a committer has asked for more details, this tag will be added to the issue. The issue will not proceed in its lifecycle until the filer provides the requested information. If an issue sits in the triaged and needinfo state for too long, it will be closed.|
|If a committer has looked at the issue and verified that the problem exists and is reproducable, this tag will be added. This tag does not mean that someone is actively working on the issue, just that the issue is valid.|
|If a committer has looked at the request and determined it is suitable for Orion, this tag is added. This tag does not mean that someone is actively working on the issue, just that the issue is valid.|
|If the issue cannot be verified, or is spam, not appropriate for Orion, or is not an issue (something that would be better discussed on mattermost or the mailing list), this tag will be addedd and the issue closed.|
|If the issue (mostly for enhancement requests) is not ever planned to be fixed, rather than leave the issue open as helpwanted, this tag will be added and the issue closed.|
|If the issue is valid (bug or enhancement), but no committers plan to work on it in the forseeable future, this tag will be added to request help from the community.|
|If the issue filed has already been fixed, or the issue cannot be reproduced, this tag is applied and the issue closed.|
Once the state of the issue has been set, there is one remaining tag that will typically be set by a committer. The severity of the issue. The severity tags follow exactly the meaning from the Eclipse bugzilla severities, except that we do not use
enhancement as severities. The filer of the issue can set this tag if desired, but take note, setting a high severity for a trivial issue will not get it fixed any faster.
Our severity tags are as follows:
|Blocks development and/or testing work. No workaround exists.|
|Crashes, loss of data, severe memory leak.|
|Major loss of function.|
|Minor loss of function, or other problem where easy workaround is present.|
|Cosmetic problem such as misspelled words or misaligned text.|
Now that we've seen the tags, lets see an example of how and when they might be applied.
###A Valid Bug Example
A new issue has just been filed and the lifecycle begins.
triagedtag and adds the
###An Invalid Bug Example A new issue has just been filed and the lifecycle begins.
invalidtag and close the issue.
There are many more examples that could be given for issue lifecycles, but in general it goes like this: new issue -> triaged -> bug or enhancement (stays open), severity and component added OR -> needsinfo, invalid, wontfix or worksforme (closed) -> fixed (closed)
There is a finite set of states that lead to an issue being closed. They are:
Once an issue has been closed, it does not mean the end. An issue can be reopened (if the fix does not work, or someone decides to work on a wontfix issue). Unless you have strong case for, or are willing to work on the issue, it is recommended to not reopen wontfix issues (or they will be reclosed).
If you have a proposed fix for a bug, you can open a pull request (thank you!). Below are the guidlines to follow to help get your fix into Orion.
Short description (fixes #1234) Longer description here if necessary