Re: [office] ODF proposal standing rule

[Michael Brauer <michael.brauer@oracle.com>]

On 07.02.2011 15:24, robert_weir@us.ibm.com wrote:

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

Michael Brauer <michael.brauer@oracle.com> wrote on 02/03/2011 07:19:18 
AM:

  

So the motion would be to replace the current standing rule with this:
  

Yes-

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

1. Any TC member may propose a substantive addition, deletion or 
change to the current working draft of the ODF specification by 
submitting a Proposal. This standing rule does not apply to editorial 
    

changes.
  

So what does apply to editorial changes?

And do we want to state this as a requirement, e.g.,:

"Any substantive additions, deletions or changes to the ODF specification 
must be initiated by a TC member by submitting a Proposal" 
  

Yes, this sounds better.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

3. For all proposals, a JIRA issue must exist. If such an issue is 
not existing at the time a proposal is made, the proposer must 
create an issue. The Proposer then must add the information requested in
the New Proposal Form on the ODF TC's wiki to the JIRA issue, with 
details of the Proposal.

    

We should link to the proposal form, and see if we still agree it is 
sufficient.

Do we mean this proposal form:  
http://wiki.oasis-open.org/office/ProposalTemplate

If so, we might want to edit it.  For example, some of the fields 
(proposer name, dates, etc.) are naturally tracked by JIRA.
  

Editing the proposal template sounds like a good idea. Where I'm not sure is whether we really should have such details in the standing rule.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

4. When the Proposal is ready for broader discussion within the TC, 
the Proposer must post a link to it to the TC's mailing list to 
solicit feedback, or add an appropriate comment to the JIRA issue. 
TC members can raise objections to a proposal by a "-1" comment, or 
agreement by a "+1" comment.

    

Might also allow intermediate values per Apache voting rules:

http://www.apache.org/foundation/voting.html
  

Yes,. Thanks for the link.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

5. The Proposer controls the content of the Proposal and the pace at
which the Proposal advances towards approval. As it is discussed on 
the mailing list or within the JIRA issue, TC members may propose 
changes to the Proposal. However, only the Proposer, and those whom 
he or she designates, may edit the proposal.

    

OK.  As we know, JIRA does not enforce this.  So we would need to be 
careful here.  When addressing public comments and defect reports we often 
had many people change the resolutions/proposals.  So we should have some 
way of distinguishing new feature proposals from an ordinary defect. Maybe 
have a component called "New Proposal"  or put "Proposal:" in the title?
  

Right. But maybe we can delete this. We had no issues with collaborating on issues so far.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

6. When the Proposer wishes for the Proposal to be discussed in a TC
meeting, he or she must notify the TC mailing list of this intent by
the Wednesday prior to the Monday TC meeting in which he or she 
wishes to discuss the Proposal, or by adding an appropriate comment 
to the JIRA issue. If the agenda cannot accommodate this discussion 
during the next TC meeting, the Chair(s) should ensure that the 
discussion is scheduled for the next available TC meeting, with no 
new notification by the Proposer needed. A Proposal may be discussed
in multiple TC meetings.

    

I would remove this from the standing rule.  If we want, we could have a 
separate standing rule on the agenda, and how TC members can add items to 
the agenda for discussion in general.  But I don't think we want to 
require that all new proposals be discussed on a call.
  

Yes.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

7. When the completion of  a proposal has been announced, when the 
proposal is detailed enough to be integrated into the specification,
and when no objections are raised in the issue within one week, the 
TC editors may integrate the proposal. Already integrated proposals 
may be revised or amended by subsequent proposals. No Proposal shall
be voted on unless it formally meets the definition of 
"contribution" as defined by OASIS IPR Policy.

    

OK.  So this answers my question above about deadlines.  A proposal must 
be available for discussion one week prior to integration.  It would be 
good if we could say what that means in terms of a CSD ballot.  Maybe 
integration takes another week, so proposals must be finalized 2 weeks 
prior to a CSD target date?  Either that, or we take the CSD targets to 
mean "final date for proposals to be entered" and know that the actual CSD 
ballot would be 2 weeks later.
  

I think most of this actually belongs into the TC schedule rather than into the standing rule. But we should indeed ad a sentence that proposals are only integrated if the TC schedule permits this.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

8. When objections are raised to a proposal, the Proposer may 
request a vote to accept his or her Proposal. He or she must notify 
the TC mailing list of this intent by the Wednesday prior to the 
Monday TC meeting in which he or she wishes to have the vote. If the
agenda cannot accommodate this vote during the next TC meeting, the 
Chair(s) should ensure that the vote is scheduled for the next 
available TC meeting, with no new notification by the Proposer 
needed. Simple Majority Vote shall determine whether a Proposal is 
approved or not.

    

I assume we could also resolve objections via an electronic ballot?  That 
would be slower than a vote on the next TC call, but faster than waiting 2 
weeks, if there was a holiday or the agenda at the next TC call as already 
full.
  

Isn't this also a detail of how items get to the agenda, that we should delete from the standing rule?

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

9. When notifications mentions in this standing rule are made using 
JIRA, the TC member that notifies should ensure that JIRA sends a 
copy of the notification to the TC mailing. In doubt, a 
notifications should be made on the TC mailing list.

    

I would encourage us to do everything possible in JIRA.  A note sent to 
the mailing list that is not connected to a JIRA issue will easily be 
lost.
  

In principle yes. But JIRA does not always send out notifications and there are a lot of field that may be set to wrong values causing issues (and with them requests in issues) to disappear. It is however unlikely that requests on the mailing list are overlooked. I therefore would like to keep the possibility that TC members make requests on the mailing list for the case notifications in JIRA are not noticed.

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

We might also think about tracking agenda items on the wiki. 

For example, what if we had a wiki page called "Proposed TC Agenda Items". 
 We know that any TC  call will have certain formal agenda items, the 
roll-call, approval of agenda, minutes, etc.  We know that these take 
around 20 minutes.   But we could have TC members maintain a list of 
proposed agenda items on the wiki, each one naming a topic, a speaker, and 
a time estimate, and when we form the agenda each week, we could consult 
with that wiki page to fill out the official agenda according to the 
available time.
  

Sounds like a good idea. but I don't know if we need that at this stage. Right now, we have more time in TC calls than topics to discuss. This may change of course, but I would wait with rules regarding how we set up the agenda if we really run into trouble setting it up properly.

Michael

OF2D8E74B4.7FAD527D-ON85257830.004BF3FD-85257830.004EC396@lotus.com" type="cite">

-Rob

  

Best regards

Michael
-- 
[image removed] 
Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

[image removed] Oracle is committed to developing practices and 
products that help protect the environment 
    

--

Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle is committed to developing practices and products that help protect the environment