New .lst Tag process

Introduction

This process covers the path from a LST Syntax FREQ first being entered, to the Data-approved spec'ed out tracker that is handed of to Code for implementation or the possible rejection of the FREQ. It is going to be effective as of May 1st, 2006.

The organ that is used to spec out and approve new or changed LST syntax is the discussion of the Feature Request on the PCGen_Experimental group on Yahoo Groups. To be able to do this, we need get all relevant FREQs to be posted on this group. There are 3 different types of Feature Requests that we have to deal with:

1. User FREQS entered on one of the lists

2. User FREQS entered as tracker

3. FREQS entered by a Team Member

For point 1 the various discussion lists need to be scanned and all relevant FREQS be forwarded to Experimental. Also a reply to the original message is to be given that this FREQ has entered the Feature Request Evaluation Process on PCGen_Experimental. This is the task of the Data Liaison TM.

For point 2 the user entered FREQs that were directly entered as a tracker need to be surveyed and posted as a proposal on Experimental. This needs also be replied to in the trackers in point 1. This is also the task of the Data Liaison TM.

For point 3 Team members should post their proposals directly at Experimental.

A tracker category called "Development Specs" is used to track the advancement of the discussion. When a FREQ enters the process, a tracker in the new category is to be created for it by the Data Liaison TM. The purpose of these trackers is not to discuss the spec itself on them, but to keep track of which discussions are going on, how long they are going on, and finally the decision if a FREQ has been refused or accepted will be noted in them. This will also allow us to see if a refused Freq gets requested again repetitiously. For user entered FREQ trackers, a link to that tracker needs to be included.

FREQs should then be discussed, any subscriber to PCGen_Experimental may take part in this discussion. At the time when 2 Data Chimps have agreed on a syntax, the proposal will have to rest for 1 week. In that time any Data Chimp can lay in protest against the Freq, which will restart the discussion. The cut-off date for the protest is to be posted in the Development Spec tracker. This should be done by one of the involved Data Chimps. In case the discussion moves into an impasse because of a dispute between the Data Chimps, the Content Silverback will adjudicate.

Once a FREQ has passed this process, it is entered as a Feature Request tracker or the result of the discussion is posted on the existing user entered tracker. This would usually be done by the Data Liaison TM, but if the discussion was long and complicated and spreads its results over multiple posts, one of the involved Data Chimps should take this on. If it was a user FREQ from one of the other lists, there needs to be another reply either stating why the FREQ was refused or pointing to the resulting Feature Request tracker. The Development Specs tracker needs to have the result stated and a link to the Feature Request tracker is to be entered if a new one has come forth.

To keep an eye on proposed FREQs where the discussion has stalled, the Data Liaison TM will check once a week, whether a discussion hasn't seen a reply within that week. In that case the thread is to be bumped with a [WAKE_UP] tag in the subject line. If that still doesn't lead to a new discussion within 2 or 3 days, then the Content Silverback is to be contacted directly.

To make the tasks of the Data Liaison TM easier, each FREQ that enters the discussion on Experimental is to be tagged [PROPOSAL]. Also a discussion that has finished should be tagged as [TRACKERED].

Of course no rule without exception, so there are 2 cases that are exempt from this process:

Pre-existing FREQS
Anything that has been trackered as a FREQ before May 1st, 2006 can continue as before. We currently have over 250 Feature Requests, the majority of them concerning LST syntax. If we put them all on hold and tried to run them through this process, the process would break under the burden. If later tracker reviews reveal a FREQ that would benefit from the process, the Content SB may still decide to let that run through it, but doing so is optional.

RC FREQS
If the need for a special FREQ is encountered while PCGen is in Release Candidate state, or even in a late Beta state, the process may prove too slow for that. The Content Silverback can then decide to let a Feature Request pass without running through the process.