Re: [office] ODF New Proposal Form (draft)

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

I agree to Rob's observations and suggestion, and fully support them.

Formalizing and structuring the proposal workflow may be a little bit 
more work for proposers compared to the informal workflow we have today, 
but I think we will substantially benefit from this.

The only suggestion I have is that we for larger proposals (whatever 
that means) use ODF documents for the text/schema change requests rather 
than the Wiki itself (which means that the "Requested changes to the ODF 
Standard" section, and only that section, would be a link to a document 
in the TC repository). This may save us significant work when 
integrating them into the specification document.

Michael

robert_weir@us.ibm.com wrote:
> 
> 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


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering