OASIS Open Document Format for Office Applications (OpenDocument) TC

ODF New Proposal Form (draft)

  • 1.  ODF New Proposal Form (draft)

    Posted 05-20-2008 22:15

    I'm always looking for ways to make my life easier.   I'm not particular good at tracking things.  I'm not a project manager.  One thing I have noticed I am particularly bad at is tracking week-to-week information in the agendas and the minutes and the wiki.   This probably worked better when Michael was the sole TC Chair, but now we alternate chairing meetings, and lately I feel like I've let things fall between the cracks or get lost.  This is why I proposed tracking the Action Items in Kavi.  I think that has worked well so far.  It makes things easier for me, and smoother for all of us.

    Another area that concerns me is the feature proposals for ODF.  We currently track them in this wiki page:  http://wiki.oasis-open.org/office/OpenDocument_v1.2_Action_Items

    Items are proposed on the mailing list, get noticed by one of the Chairs (usually Michael) who adds them to the wiki.  We then discuss on the list, discuss in meetings and eventually come to some sort of decision.

    But it isn't as crisp and unambiguous as I'd like it to be.  What determines whether something is a real proposal on the list versus a "Gee, wouldn't it be nice if..." posting?  How do we know when a proposal is ready to be voted on?  When is a proposal suitable for voting?  Is it enough to just have a rough outline?  Or does it need to be fully defined?  How do we know what proposals should first be reviewed by the Accessibility SC?

    As we finish up ODF 1.2 and move onto ODF 1.3 (or ODF 2.0) I'd like the TC to consider submitting itself to a more disciplined approach to making and tracking feature proposals.  It is a little more work for the proposer, but I think it will increase our overall effectiveness by ensuring that all issues related to a proposal are raised and documented in one place.  It will also ensure that nothing gets lost between the cracks.

    You can get a sense of what I'm suggesting by looking at this draft of a "New Proposal Form" which (if the TC approves of this approach) would be required for all new substantive proposals (anything above the level of a simple editorial change):  http://wiki.oasis-open.org/office/New_Proposal_Form

    The idea is to put more control into the hands of the Proposer.  They would initiate a new proposal by creating a new Wiki page, using this form as a template, and filling out the details related to their proposal.  At first it might be a rough draft, but all sections would need to be completed before it could be voted on.  Once even the rough draft of the form is entered, discussion could occur on the list to refine the idea.  Once the Proposer determines that the proposal is ready, then he/she would let one of the Chair's know, and we would schedule it for a vote at a future TC call.  The Chairs would track the progress of the proposal in the "workflow" section, indicating when the proposal was made, when discussed on the TC call, when voted on, etc.

    I'm not wedded to the exact form or questions asked in the form, but I think there are certain background questions we should ask of every proposal, such as accessibility impact, etc.  

    Any thoughts on this?  I don't want to turn this into the kind of project management  hell many of us already face in our day jobs, but I think that a little more structure to this, as outlined above, would give substantial benefits.

    If the TC agrees, I would follow up by making requested changes to the Proposal Form, drafting some proposal workflow rules, and getting this all into a form that the TC can then adopt as "standing rules" in accordance with section 2.9 of the OASIS Technical Committee Process (http://www.oasis-open.org/committees/process.php#procedure)

    -Rob