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