OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC members, we currently have a standing rule which covers how we work on feature proposals. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office We approved this standing rule before we had JIRA, and it is tailored to the Wiki based work flow we had in place before we had JIRA. Since we agreed to use JIRA to work on feature proposal, it seems appropriate to amend the standing rule. A proposal is below: 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. 2. A TC member wishing to make a Proposal (the Proposer) should first announce their intention to make a Proposal on the ODF TC's mailing list or by adding a comment to a JIRA issue. Detail is not needed at this point, but such notification is recommended in order to let other interested TC members know that someone is working in this area and to prevent duplication of effort. The proposer must assign the issue to herself/himself, and must set the fix for field to the target for which the proposal is aimed to be ready. The proposal will only be considered for that target if it contains enough information for the TC editors to integrate it into the specifications, and if no unresolved objections are raised in the JIRA issue. 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. 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. 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. 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. 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. 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. 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. Best regards Michael -- 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

Michael Brauer <michael.brauer@oracle.com> wrote on 02/03/2011 07:19:18 AM: > > we currently have a standing rule which covers how we work on > feature proposals. > > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office > > We approved this standing rule before we had JIRA, and it is > tailored to the Wiki based work flow we had in place before we had JIRA. > > Since we agreed to use JIRA to work on feature proposal, it seems > appropriate to amend the standing rule. A proposal is below: > So the motion would be to replace the current standing rule with this: > 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" > 2. A TC member wishing to make a Proposal (the Proposer) should > first announce their intention to make a Proposal on the ODF TC's > mailing list or by adding a comment to a JIRA issue. Detail is not > needed at this point, but such notification is recommended in order > to let other interested TC members know that someone is working in > this area and to prevent duplication of effort. The proposer must > assign the issue to herself/himself, and must set the "fix for" > field to the target for which the proposal is aimed to be ready. The > proposal will only be considered for that target if it contains > enough information for the TC editors to integrate it into the > specifications, and if no unresolved objections are raised in the JIRA issue. > Should we say something about a deadline for integration? In other words, if a proposal is made, and a target is set, and the proposal has sufficient detail and no objections, is it OK if it is first submitted on the day before we have a CSD vote? I don't think this would be good, since that would give insufficient time for TC members to review or discuss the new proposal. There are two ways we could handle this: 1) Always have a 1-week electronic ballot for CSD votes, and that provides the opportunity for TC members to raise objections to problems in new proposals. or 2) Require new proposals to be marked "resolved" at least one week before the CSD ballot, so comments can be made in JIRA and the proposal possibly improved before the CSD text is completed. I think I prefer the second approach. The more we can make use of lightweight review and discussion mechanisms, like JIRA, the more efficient we are. CSD ballots are relatively heavy weight, requiring a minimum of 1 week to review, and any serious problem found then causes several weeks of delay, especially of it is intended to be a PRD also. > 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. > 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 > 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? > 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. > 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. > 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. > 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. 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. -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

Hi Rob, a few comments: - I've used the current standing rule as basis. So, some items you mention are already in that standing rule. - I've intentionally did not refer to CSD ballots, since I think schedule items should be subject to another resolution or standing rule. - I've intentionally did not include too much details regarding use of JIRA and the mailing list. I think these are details where we may have changing best practices , and we may not want to adapt the standing rule each time we adapt the best practices. Michael 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: we currently have a standing rule which covers how we work on feature proposals. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office We approved this standing rule before we had JIRA, and it is tailored to the Wiki based work flow we had in place before we had JIRA. Since we agreed to use JIRA to work on feature proposal, it seems appropriate to amend the standing rule. A proposal is below: So the motion would be to replace the current standing rule with this: 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 2. A TC member wishing to make a Proposal (the Proposer) should first announce their intention to make a Proposal on the ODF TC's mailing list or by adding a comment to a JIRA issue. Detail is not needed at this point, but such notification is recommended in order to let other interested TC members know that someone is working in this area and to prevent duplication of effort. The proposer must assign the issue to herself/himself, and must set the fix for field to the target for which the proposal is aimed to be ready. The proposal will only be considered for that target if it contains enough information for the TC editors to integrate it into the specifications, and if no unresolved objections are raised in the JIRA issue. Should we say something about a deadline for integration? In other words, if a proposal is made, and a target is set, and the proposal has sufficient detail and no objections, is it OK if it is first submitted on the day before we have a CSD vote? I don't think this would be good, since that would give insufficient time for TC members to review or discuss the new proposal. There are two ways we could handle this: 1) Always have a 1-week electronic ballot for CSD votes, and that provides the opportunity for TC members to raise objections to problems in new proposals. or 2) Require new proposals to be marked resolved at least one week before the CSD ballot, so comments can be made in JIRA and the proposal possibly improved before the CSD text is completed. I think I prefer the second approach. The more we can make use of lightweight review and discussion mechanisms, like JIRA, the more efficient we are. CSD ballots are relatively heavy weight, requiring a minimum of 1 week to review, and any serious problem found then causes several weeks of delay, especially of it is intended to be a PRD also. 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. 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 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? 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. 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. 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. 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. 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. -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

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