Development Process
From Imprudence
The development process and strategy for Imprudence will almost certainly shift and be adjusted over time as the situation evolves, but this page describes the current vision for that process.
Contents |
About Volunteer Efforts
Obviously, because Imprudence depends on volunteer effort, it's impossible to dictate what aspects of the viewer any person will work on. The Imprudence project leads can put forward and recommend a specific focus, but ultimately it is up to each individual developer or designer to step up and work on the parts of the viewer that he or she considers most important.
Wishlist
We are keeping a wishlist of features, improvements, and bug fixes that would improve usability (or, in a few cases, would just be really nice to have). There are three important things to understand about that list:
- The wishlist is open and unofficial. Anyone can add items to the wishlist. For this reason, do not assume that everything on the wishlist is endorsed or recommended by the Imprudence project leads.
- The wishlist is not a roadmap. Not everything on the wishlist will get done, nor do we plan on getting them all done. Rather, the idea is to present a wide variety of ideas and let volunteers choose which ones they want to work on.
- The wishlist is not comprehensive. It merely serves as inspiration and a focal point for development efforts. There are a lot of worthy goals that are not on that list. Volunteers are encouraged to work on things they feel strongly about, even if those things are not listed.
Major and Minor Features
Most features implemented from the wishlist will be what we consider minor features. These are smallish features that would generally take one person less than a month to implement. By contrast, major features are much larger undertakings, perhaps requiring a team of 2-5 people working together for a few months.
The change in version number reflects the addition of these two types of features:
- A release that includes one or more minor features will increment the minor version number, e.g. from 1.0.0 to 1.1.0. If possible, there should be a minor version release every month or two.
- A release that includes a major feature will increment the major version number, e.g. from 1.1.0 to 2.0.0. Major releases will occur much less frequently than minor ones.
Advocates
Although volunteers are free to work on whatever aspects they wish, ideas with a lot of popular support are more likely to attract the attention of volunteers. So, even people who are not designers or developers can play an important role in influencing the development of Imprudence, by advocating for issues (either issues on the wishlist or their own ideas).
Unlike Linden Lab with their JIRA, Imprudence does not (currently) have a formal system for voting on an issue. Instead, advocates should create a thread in the forums (if one doesn't already exist) for supporters (and opponents) of the issue to discuss and express their opinions on it. Add a link on the wishlist pointing to the forum thread, so that others can easily locate it. Advocates are encouraged to blog, tweet, plurk, and otherwise spread the word about issues they support.
Keep in mind that the point of the forum thread is to convince developers and designers that an issue is an especially important and worthwhile one. Sheer number of supporters is a factor in that, but a few solid and persuasive arguments for the issue can be even more convincing.
Issue Tracker
Imprudence has an issue tracker for keeping track of bugs to fix, new features to implement, and other changes that the developers intend to make.
Working with the Source Code
Testing and Quality Control
Imprudence has no formal testing process or Quality Assurance department. Testing consists of many people actually using the viewer and making sure things work alright. Release candidates will be available in advance of every release, to give people a chance to try the viewer on their own computers and report any problems they have.
Of course, developers are expected to check that their code actually works and doesn't cause any obvious side effects. This applies when importing patches or merging Git branches, too.
Release Time
To be written...
