by andrewbuck » 07 Feb 2011, 22:59
I went through and added a whole bunch of tracker tickets from the TODO list as well as a few others related to preparing a release candidate, and then a release. I just arbitrarily set the due date for a release candidate at the end of February and the due date for the official release one week after that. That gives us a week to play around with the official release candidate and try to squash any bugs before we put out the official release (which will hopefully have no bugs in any of the officially supported features).
In addition to the bugs from the TODO list (there are still more that are not on trac yet but these are the more important ones) there are also "checkpoint" items for the release candidate. For both sounds and models there are tickets which are met when an official list of content has been created and uploaded to SVN. Any content to be "officially" included in this release (i.e. to be put in the windows zip file or in the .deb package) should meet the requirements for inclusion. Basically the only requirement is that the content and any material needed to put it together for export into the game (textures, etc) should be on the SVN in the media source directory. Once the official list of sounds and meshes are put together and finalized the corresponding tickets will be closed and someone will go through and make sure that everything on the official list is properly exported if necessary and then copied over to the Media directory. This way we can include the lists of officially supported content along with the game so when each new release comes out, players can see what has been added (i.e. 2 new creatures, new sounds for some creatures, new rooms, etc).
I just sort of threw together the dates and the criteria for official inclusion, etc so if anyone has any suggestions for changes we can look into that. I think the rules I laid out are simple enough and if followed should make putting together this release much more organized than our past several attempts. I figure we can try this method for this release and then see how we want to change it for future releases.
Finally, it would be good to assign people of official responsibility for different sections of the project corresponding to the "component" field of the ticket system. Having the ticket assigned to you does not mean that you have to fix it yourself, but it will mean that you are responsible for coordinating the effort to fix it and will be the one who clears the item when it is fixed. This means that when a new bug comes in which falls to you you try to confirm it really is a bug or mark it complete right away if it is not, then take some starting action to resolve it, either posting a comment on the trac system about it, or starting a forum thread in the appropriate place on the forum. Although I haven't assigned any yet, I was thinking of assigning the tickets to people as follows:
andrewbuck - All tickets relating to code bugs, crashes, etc, unless it relates to sound or other specific areas oln wants to work on.
oln - Coding issues relating to sound and build environment problems/development.
skorpio - All tickets relating to meshes (missing meshes, handling the mesh export to ogre, and problems with mesh scaling lighting, etc).
svenskmand - All tickets relating to sound that are not code related (some sound is too quiet/loud, missing sounds, sound format and export issues, etc).
This way we split up incoming issues amongst the group better allowing people to focus on getting the problems in their area resolved, either themselves or more likely bu just coordinating the response. Otherwise there are so many issues going on at any given time that one person can't keep track of them and things get forgotten about.
-Buck