Hi all, please find attached the promised proposal for the PGI decision-making procedures (which looks just like a bylaw now). It is longer than half a page, but it's basically a formatting matter. If it is formatted without bullets (like the "Quorum" section), it gets shorter. Preamble can be removed as well, if we are into saving ink and paper. Cheers, Oxana
Dear Oxana, thanks for your efforts. Let's schedule 1/2 hour in the telcon today to discuss and refine it where needed. All, please feel free to comment already so that our discussions today can be shortened. Take care, Morris
-- -----Ursprüngliche Nachricht----- -- Von: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] Im Auftrag von Oxana Smirnova -- Gesendet: Donnerstag, 18. November 2010 02:04 -- An: pgi-wg@ogf.org -- Betreff: [Pgi-wg] PGI bylaws -- -- Hi all, -- -- please find attached the promised proposal for the PGI decision-making procedures (which looks just like a bylaw -- now). -- -- It is longer than half a page, but it's basically a formatting matter. If it is formatted without bullets (like -- the "Quorum" section), it gets shorter. Preamble can be removed as well, if we are into saving ink and paper. -- -- Cheers, -- Oxana
Morris, Johannes and all, The 'PGI decision-making guidelines (bylaw)' proposed by Oxana SMIRNOVA could perhaps be useful, and I would accept them. In fact, I am afraid that inside PGI, the main issue is not so much : Who is allowed to vote ? but rather : Who is willing to devote time to : - study and understand the issues ? - provide inputs, diagrams and proposals for Use cases, Issues, Requirements, Specifications, Conformance tests, ... following the best practices of software engineering ? - study, constructively criticize, and improve proposals, with good traceability ? - write down documents presenting the collected (and hopefully agreed) Use cases, Issues, Requirements, Specifications, Conformance tests, ... ? Personally, I have tried to perform the above mentioned work : - Input text for Security : http://forge.gridforum.org/sf/go/doc15584 - State Diagram for Job management : http://forge.gridforum.org/sf/go/doc15881 - Diagram presenting Useful Official and De facto Standards : http://forge.gridforum.org/sf/go/doc15990 - Wiki permitting traceability for each requirement : http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Requirem... - 3 Sequence diagrams describing the relationship between Jobid structure and Endpoint migration : http://forge.gridforum.org/sf/go/doc16006 http://forge.gridforum.org/sf/go/doc16007 http://forge.gridforum.org/sf/go/doc16008 - Glossary and Terms : http://forge.gridforum.org/sf/go/doc16036 - 3 EDGI Use cases : In particular http://forge.gridforum.org/sf/go/doc16010 - Chart + Explanations for the PGI priorities : http://forge.gridforum.org/sf/go/doc16156 - Precise proposal of specification for Publication of Endpoint Security Setup using GLUE 2.0 : http://forge.gridforum.org/sf/go/doc16157 - Proposal of specification for the usage of GLUE 2.0 inside JSDL : http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD3 Let us work with enthusiasm ! Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Thu, 18/11/2010 02:04, Oxana Smirnova wrote:
Hi all,
please find attached the promised proposal for the PGI decision-making procedures (which looks just like a bylaw now).
It is longer than half a page, but it's basically a formatting matter. If it is formatted without bullets (like the "Quorum" section), it gets shorter. Preamble can be removed as well, if we are into saving ink and paper.
Cheers, Oxana
I agree with Etienne with respect to the "but rather". A -----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Etienne URBAH Sent: Wednesday, December 08, 2010 2:31 PM To: Morris RIEDEL; Johannes WATZL; pgi-wg@ogf.org Cc: edgi-na2@mail.edgi-project.eu; lodygens@lal.in2p3.fr Subject: Re: [Pgi-wg] PGI bylaws and work Morris, Johannes and all, The 'PGI decision-making guidelines (bylaw)' proposed by Oxana SMIRNOVA could perhaps be useful, and I would accept them. In fact, I am afraid that inside PGI, the main issue is not so much : Who is allowed to vote ? but rather : Who is willing to devote time to : - study and understand the issues ? - provide inputs, diagrams and proposals for Use cases, Issues, Requirements, Specifications, Conformance tests, ... following the best practices of software engineering ? - study, constructively criticize, and improve proposals, with good traceability ? - write down documents presenting the collected (and hopefully agreed) Use cases, Issues, Requirements, Specifications, Conformance tests, ... ? Personally, I have tried to perform the above mentioned work : - Input text for Security : http://forge.gridforum.org/sf/go/doc15584 - State Diagram for Job management : http://forge.gridforum.org/sf/go/doc15881 - Diagram presenting Useful Official and De facto Standards : http://forge.gridforum.org/sf/go/doc15990 - Wiki permitting traceability for each requirement : http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Requirem... - 3 Sequence diagrams describing the relationship between Jobid structure and Endpoint migration : http://forge.gridforum.org/sf/go/doc16006 http://forge.gridforum.org/sf/go/doc16007 http://forge.gridforum.org/sf/go/doc16008 - Glossary and Terms : http://forge.gridforum.org/sf/go/doc16036 - 3 EDGI Use cases : In particular http://forge.gridforum.org/sf/go/doc16010 - Chart + Explanations for the PGI priorities : http://forge.gridforum.org/sf/go/doc16156 - Precise proposal of specification for Publication of Endpoint Security Setup using GLUE 2.0 : http://forge.gridforum.org/sf/go/doc16157 - Proposal of specification for the usage of GLUE 2.0 inside JSDL : http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD3 Let us work with enthusiasm ! Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Thu, 18/11/2010 02:04, Oxana Smirnova wrote:
Hi all,
please find attached the promised proposal for the PGI decision-making procedures (which looks just like a bylaw now).
It is longer than half a page, but it's basically a formatting matter. If it is formatted without bullets (like the "Quorum" section), it gets shorter. Preamble can be removed as well, if we are into saving ink and paper.
Cheers, Oxana
Dear PGI, Since this proposal first appeared on the PGI list it has been the subject of two OGF Board conversations. As conversation on it had apparently ceased we had thought it had gone away... but still appears to be in contention. OGF standards are founded on two important concepts: * Open and transparent process * Rough Consensus Your proposal breaks these concepts in two ways. By having identified voters you are stopping any member of OGF being a stakeholder in the work of the group. This is not acceptable. Rough consensus is not needed for the circulation of draft documents - so feel free to circulate ideas within the group as they develop. For a document to be submitted into the document process in order to lead to a standard it needs to have group consensus or be an individual submission. Rough consensus is something that takes time and work from the group chairs or the document editors to achieve. It requires many iterations and edits in the document. It means having to understand the different views and appreciating where they come from, even if you don't agree with them. Imposing a closed voting system in a WG is not something OGF can support. Regards, Steven for the OGF Board
Hi Steven, many thanks for the explanations! In practice, I can not see how a consensus (even rough) can be achieved when every OGF member is a stakeholder. This probably simply means that the group chair makes qualified decisions after evaluating *all* opinions. This in turn implies really a lot of work and deep expertise in the subject on the part of the chair. Or do you have some other mechanisms to suggest? Cheers, Oxana On 14.12.2010 11:56, Steven Newhouse wrote:
Dear PGI,
Since this proposal first appeared on the PGI list it has been the subject of two OGF Board conversations. As conversation on it had apparently ceased we had thought it had gone away... but still appears to be in contention.
OGF standards are founded on two important concepts: * Open and transparent process * Rough Consensus
Your proposal breaks these concepts in two ways. By having identified voters you are stopping any member of OGF being a stakeholder in the work of the group. This is not acceptable. Rough consensus is not needed for the circulation of draft documents - so feel free to circulate ideas within the group as they develop. For a document to be submitted into the document process in order to lead to a standard it needs to have group consensus or be an individual submission.
Rough consensus is something that takes time and work from the group chairs or the document editors to achieve. It requires many iterations and edits in the document. It means having to understand the different views and appreciating where they come from, even if you don't agree with them.
Imposing a closed voting system in a WG is not something OGF can support.
Regards,
Steven for the OGF Board _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
On Tue, Dec 14, 2010 at 3:06 PM, Oxana Smirnova <oxana.smirnova@hep.lu.se> wrote:
Hi Steven,
many thanks for the explanations!
In practice, I can not see how a consensus (even rough) can be achieved when every OGF member is a stakeholder. This probably simply means that the group chair makes qualified decisions after evaluating *all* opinions. This in turn implies really a lot of work and deep expertise in the subject on the part of the chair.
Yes. Voting can be a tool, to be employed by the chairs, to help to evaluate group opinions, and to judge level of consensus. Steven, I see what you / the board is concerned about - certainly the OGF openes should not be undermined. I don't see that danger really, at least at the moment - PGI so far has managed reasonably well to listen to all stakeholders. Best, Andre.
Or do you have some other mechanisms to suggest?
Cheers, Oxana
On 14.12.2010 11:56, Steven Newhouse wrote:
Dear PGI,
Since this proposal first appeared on the PGI list it has been the subject of two OGF Board conversations. As conversation on it had apparently ceased we had thought it had gone away... but still appears to be in contention.
OGF standards are founded on two important concepts: * Open and transparent process * Rough Consensus
Your proposal breaks these concepts in two ways. By having identified voters you are stopping any member of OGF being a stakeholder in the work of the group. This is not acceptable. Rough consensus is not needed for the circulation of draft documents - so feel free to circulate ideas within the group as they develop. For a document to be submitted into the document process in order to lead to a standard it needs to have group consensus or be an individual submission.
Rough consensus is something that takes time and work from the group chairs or the document editors to achieve. It requires many iterations and edits in the document. It means having to understand the different views and appreciating where they come from, even if you don't agree with them.
Imposing a closed voting system in a WG is not something OGF can support.
Regards,
Steven for the OGF Board _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
-- Nothing is ever easy...
participants (6)
-
Andre Merzky -
Andrew Grimshaw -
Etienne URBAH -
Morris Riedel -
Oxana Smirnova -
Steven Newhouse