3. Issues, Features and Releases
You are encouraged to use Github's Issues to submit new issues, or request enhancements or new features.
If you have a request for a new feature, go ahead and submit a ticket for it. You might also want to engage with the developers and discuss your idea, in case anyone else has similar ideas or is already working on a solution. Some feature requests might be considered out of scope for the software, or inappropriate for the software's target users. When creating a new ticket, you should think about whether this is a new feature, or an enhancement to an existing feature.
The software is developed along a 'scratch your own itch' philosophy, and no one expects anyone to do work for free unless it scratches one of their itches. Once you submit your request one of several things might happen:
- You find a developer in the community with the same itch, and the new feature gets developed.
- You are a developer, and you undertake the work yourself, after some discussion with the developer community.
- If you cannot find a developer to do the work for free - and yet the features are considered a good idea by the developer community - you might want to consider offering a bounty for the work to be completed.
If you are a developer, wanting to develop new features in the software we highly recommend engaging with the developer community via the xerte-dev list and discussing your ideas before you jump in and start hacking at the code.
Once upon a time, Xerte was a windows application developed by a sole developer who could just about keep track of changes to the software, and who made frequest - often daily - releases, reflecting incremental changes to the codebase, and who knew how to fix all the bugs because he had written all the code. Users reporting issues were delighted because their problems were resolved quickly, and the developer was happy because his software was constantly improving thanks to this feedback from users.
Those days are long gone. Many people have contributed code to the project since those early days, and the software has evolved from a windows application written in ActionScript to a web application using a number of different technologies, with half a dozon or more core contributors all working on different features simulataneously.
Rolling out bug fixes to users of a windows application is easy: we used to be able to simply update the installer and ask users to run it to fix their bugs. Now, with the software installed on a web server, it is much more difficult for fixes to be applied quickly. This makes testing very important.
Any ideas for a feature can be submitted by any member of the community to the list on github. The idea might be discussed on the xerte-dev list. Some ideas might be rejected at this stage. Ideas that survive have the potential to be new features. Those requesting the feature may consider how they can help bring it to fruition.
At the beginning of a release cycle, the committers / PMC decide which features to include in the next release, and a tentative release date is established. Whilst anyone can suggest an idea, the PMC will ensure that there is resource available to make it a reality.
The development work then proceeds. Anything notable for testing is identified and a testing strategy defined.
Testing Completes with a vote to make the release, and the release is made.