Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Lucas Nussbaum]

On 06/12/14 at 13:26 -0800, Steve Langasek wrote:
> On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote:
> > Rationale
> > -
> > First, I think that there is wide agreement that a more regular
> > turn-over among TC members would be a good thing. And both Stefano's
> > and this proposal aim at addressing this, by ensuring that at least 2
> > members of the TC are replaced every year.
> 
> > However, too much turn-over, with more than 2 replacements at one point
> > of time, might have negative effects too. The TC might be temporarily
> > weakened by having more young members; replacing more than two members
> > at one point will cause less replacements later; it increases the
> > difficulty of finding new members.
> 
> > The recent situation, with three TC members resigning, should not be
> > treated as exceptional in the context of this resolution. If it were to
> > happen again, I don't think that we should add one or two automatic
> > expirations to the three resignations.
> 
> > This proposal differs from the original proposal by counting all
> > resignations and removals as part of the desirable "2 per year"
> > replacement rate, so that the total number of replacements does not
> > exceed two if only one or two younger members decide to resign.
> 
> > This version of the proposal could even result in an internal TC
> > discussion: "OK, the Project wants two members to be replaced. Are there
> > members that feel like resigning now? Or should we just fallback to the
> > default of expiring the two most senior members?". I think that such a
> > discussion would be a healthy way for each TC member to evaluate its
> > status. The orignal proposal could have the detrimental effect of
> > pushing inactive/demotivated members to stay on the TC until their
> > expiration, to avoid causing additional churn.
> 
> The pathological corner case here appears to be that the longest-serving
> member of the TC could evade the term limit indefinitely.  A scenario that
> assumes good faith on the part of all TC members is:
> 
>  - The longest-serving member of the TC spends a minimum amount of time
>engaging with TC issues.  They vote on all resolutions, but don't spend
>much time cross-examining the petitioners, nor do they participate in
>resolution drafting.  From their perspective, they are doing their duty
>on the TC, but other members of the TC have a faster response time to
>issues and therefore wind up doing the bulk of the work.
>  - The other members of the TC all are very passionate about their work on
>the committee.  (They've all been serving less than 3 years, so they have
>a lot of passion for it.)  They engage with every issue, spend several
>hours each week on trying to make the TC serve the needs of the project
>as best they know how.  And once or twice each year, there is a big issue
>that lands on the TC's desk, with social and technical issues intertwined
>and that require a lot of energy to pick apart.  Once a year, one of
>these issues further devolves into a public flamewar where the ethics of
>the TC members themselves are called into question.  And as a result, two
>members of the TC per year resign.
>  - With the minimum turnover requirement met, the longest-serving member
>continues to serve as long as they are comfortable doing so.
> 
> Did you consider this corner case in your analysis?  If you think this
> corner case is less important than the risk of high turnover in the TC,
> could you elaborate why you think this?

Your scenario describes a case where a member of the TC fullfills their
voting duties, but does not otherwise really participate in TC work.
This can happen, but I don't really see a correlation between this
happening, and the seniority of that specific TC member.

One could imagine a scenario where a recently-appointed TC member goes
semi-MIA very early, and still stay on the TC for 4 years. After all, in
Debian teams, people go MIA for various reasons, and this is not
correlated with their seniority in those particular teams.

I think that the root goal of this GR is to force more turn-over in the
TC, which is a very desirable thing. Doing that by removing the most
senior members every year is a reasonable default choice.

However, the goal of this GR is NOT to provide a mechanism to
automatically 'expire' poorly-performing TC members. I am not sure that
this is necessary: we already have a mechanism to remove members of the TC
(§6.2.5),  which has already been used in situations where members of
the TC had become inactive. I doubt that we need more than that.

Also, if the version of the GR I proposed gets chosen, I hope
that the fact that resignations or removals can 'save' other members
from expiration will result in yearly discussions where the status and
activity level of each member gets reviewed, which could actually help
address the general problem of semi-MIA TC members.

Lucas


signa

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Steve Langasek]

On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote:
> Rationale
> -
> First, I think that there is wide agreement that a more regular
> turn-over among TC members would be a good thing. And both Stefano's
> and this proposal aim at addressing this, by ensuring that at least 2
> members of the TC are replaced every year.

> However, too much turn-over, with more than 2 replacements at one point
> of time, might have negative effects too. The TC might be temporarily
> weakened by having more young members; replacing more than two members
> at one point will cause less replacements later; it increases the
> difficulty of finding new members.

> The recent situation, with three TC members resigning, should not be
> treated as exceptional in the context of this resolution. If it were to
> happen again, I don't think that we should add one or two automatic
> expirations to the three resignations.

> This proposal differs from the original proposal by counting all
> resignations and removals as part of the desirable "2 per year"
> replacement rate, so that the total number of replacements does not
> exceed two if only one or two younger members decide to resign.

> This version of the proposal could even result in an internal TC
> discussion: "OK, the Project wants two members to be replaced. Are there
> members that feel like resigning now? Or should we just fallback to the
> default of expiring the two most senior members?". I think that such a
> discussion would be a healthy way for each TC member to evaluate its
> status. The orignal proposal could have the detrimental effect of
> pushing inactive/demotivated members to stay on the TC until their
> expiration, to avoid causing additional churn.

The pathological corner case here appears to be that the longest-serving
member of the TC could evade the term limit indefinitely.  A scenario that
assumes good faith on the part of all TC members is:

 - The longest-serving member of the TC spends a minimum amount of time
   engaging with TC issues.  They vote on all resolutions, but don't spend
   much time cross-examining the petitioners, nor do they participate in
   resolution drafting.  From their perspective, they are doing their duty
   on the TC, but other members of the TC have a faster response time to
   issues and therefore wind up doing the bulk of the work.
 - The other members of the TC all are very passionate about their work on
   the committee.  (They've all been serving less than 3 years, so they have
   a lot of passion for it.)  They engage with every issue, spend several
   hours each week on trying to make the TC serve the needs of the project
   as best they know how.  And once or twice each year, there is a big issue
   that lands on the TC's desk, with social and technical issues intertwined
   and that require a lot of energy to pick apart.  Once a year, one of
   these issues further devolves into a public flamewar where the ethics of
   the TC members themselves are called into question.  And as a result, two
   members of the TC per year resign.
 - With the minimum turnover requirement met, the longest-serving member
   continues to serve as long as they are comfortable doing so.

Did you consider this corner case in your analysis?  If you think this
corner case is less important than the risk of high turnover in the TC,
could you elaborate why you think this?

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Matthew Vernon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

 Lucas Nussbaum  writes:
 
 > ===
 > The Constitution is amended as follows:
 > 
 > ---
 > --- constitution.txt.orig2014-11-17 18:02:53.314945907 +0100
 > +++ constitution.2-R.txt 2014-11-24 10:24:42.109426386 +0100
 > @@ -299,8 +299,22 @@
 > Project Leader may appoint new member(s) until the number of
 > members reaches 6, at intervals of at least one week per
 > appointment.
 > -5. If the Technical Committee and the Project Leader agree they may
 > +5. A Developer is not eligible to be (re)appointed to the Technical
 > +   Committee if they have been a member within the previous 12 months.
 > +6. If the Technical Committee and the Project Leader agree they may
 > remove or replace an existing member of the Technical Committee.
 > +7. Term limit:
 > + 1. On January 1st of each year the term of any Committee member
 > +who has served more than 54 months (4.5 years) and who is one
 > +of the N most senior members automatically expires. N is
 > +defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of
 > +former members of the Technical Committee who have resigned,
 > +or been removed or replaced within the previous 12 months.
 > + 2. A member of the Technical Committee is said to be more senior
 > +than another if they were appointed earlier, or were appointed
 > +at the same time and have been a member of the Debian Project
 > +longer. In the event that a member has been appointed more
 > +than once, only the most recent appointment is relevant.
 >  
 >6.3. Procedure
 >  
 > ---
 > ===
 
Seconded.
 
Regards,

Matthew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iQIcBAEBCgAGBQJUgW70AAoJEBL00hyPamPIW3MP/2GAmlklhQvMN7EMwjh3e597
WhpfKgK4IrxyhpNMiX7hU1k8nAswTc7AGGtdKB+gEfwrK+jGTpPVCml8tHtNANmE
kbj1BY3ETXUeJjQoE4Zn+z7kr8tpGG/d1szb9Pun144ULc1gg3ZvZ714k0MxX0AH
9VWCWkxZpuVFt6TKnlv+gLvQU6nfs1r9HjfLr7i8prIjgdxNnEjABcLl6ZCfJUSv
qx5JYXTjgEvxKnrbTHGstkEgiP4Lm+qD6N1xxn9bveSmXtVoMF8z54JpBzlSfuEV
cSaW2K8dR5BbcTHR1ee5J5IETYVRrEIVbdlktJoPAPDsXL9ODDxTO+agKxGDerGn
K1JGV3ZBbqWqfPDZPHMZvYVGR0HAbUTKTT8ml0ITaVqlE3mBJCYNlIbfZBoDaa36
Qfd1/tZjVMziPuLTkQL6NSXRalCJvKfHPDFY2u+lhtgCZDCB+Ip7onGRDvnKRxtn
V5TOByBYEPQe/TM1H/OMINaMSrddWd7NXteWE7GttHHQZjRlNGQWTyMOAWIqA8Fi
H+JdiDyfM6knibliQ6B33cMm0jyLOKRNQEtoId+Gtt8LfkA3NJhvonBEk59xN8gM
SlFU4KKuDt09Kxx4LgQpEELUl8BEzNSmdxPh4XTd6jwzWG4GZO8kckdBh86JqniI
mvKEgibxK2t5PU9cc8J2
=beob
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21633.28410.886010.665...@aragorn.weathertop.principate.org.uk

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Colin Tuckley]

On 01/12/14 13:37, Lucas Nussbaum wrote:

> ===
> The Constitution is amended as follows:
> 
> ---
> --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
> +++ constitution.2-R.txt  2014-11-24 10:24:42.109426386 +0100
> @@ -299,8 +299,22 @@
> Project Leader may appoint new member(s) until the number of
> members reaches 6, at intervals of at least one week per
> appointment.
> -5. If the Technical Committee and the Project Leader agree they may
> +5. A Developer is not eligible to be (re)appointed to the Technical
> +   Committee if they have been a member within the previous 12 months.
> +6. If the Technical Committee and the Project Leader agree they may
> remove or replace an existing member of the Technical Committee.
> +7. Term limit:
> + 1. On January 1st of each year the term of any Committee member
> +who has served more than 54 months (4.5 years) and who is one
> +of the N most senior members automatically expires. N is
> +defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of
> +former members of the Technical Committee who have resigned,
> +or been removed or replaced within the previous 12 months.
> + 2. A member of the Technical Committee is said to be more senior
> +than another if they were appointed earlier, or were appointed
> +at the same time and have been a member of the Debian Project
> +longer. In the event that a member has been appointed more
> +than once, only the most recent appointment is relevant.
>  
>6.3. Procedure
>  
> ---
> ===

Seconded

-- 
Colin Tuckley  |  +44(0)1223 830814  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x38C9D903

A day without radiation is a day without sunshine.



signature.asc
Description: OpenPGP digital signature

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/01/2014 02:37 PM, Lucas Nussbaum wrote:
> [ Cross post -vote, -project ; M-F-T: to -vote ]
> 
> Hi,
> 
> I am hereby formally submitting an alternative proposal, between 
> double-dashed lines below (formally it's an "amendment", but I don't expect
> Stefano to accept it, as we discussed it before). I am also calling for
> seconds (see below).
> 
> ===
>
> 
The Constitution is amended as follows:
> 
> ---
>
> 
- --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
> +++ constitution.2-R.txt  2014-11-24 10:24:42.109426386 +0100 @@ -299,8
> +299,22 @@ Project Leader may appoint new member(s) until the number of 
> members reaches 6, at intervals of at least one week per appointment. -
> 5. If the Technical Committee and the Project Leader agree they may +5.
> A Developer is not eligible to be (re)appointed to the Technical +
> Committee if they have been a member within the previous 12 months. +6.
> If the Technical Committee and the Project Leader agree they may remove or
> replace an existing member of the Technical Committee. +7. Term limit: 
> + 1. On January 1st of each year the term of any Committee member +
> who has served more than 54 months (4.5 years) and who is one +
> of the N most senior members automatically expires. N is +
> defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of +
> former members of the Technical Committee who have resigned, +
> or been removed or replaced within the previous 12 months. + 2. A
> member of the Technical Committee is said to be more senior +
> than another if they were appointed earlier, or were appointed +
> at the same time and have been a member of the Debian Project +
> longer. In the event that a member has been appointed more +
> than once, only the most recent appointment is relevant.
> 
> 6.3. Procedure
> 
> ---
>
> 
===
> 
> Rationale - First, I think that there is wide agreement that a more
> regular turn-over among TC members would be a good thing. And both
> Stefano's and this proposal aim at addressing this, by ensuring that at
> least 2 members of the TC are replaced every year.
> 
> However, too much turn-over, with more than 2 replacements at one point of
> time, might have negative effects too. The TC might be temporarily weakened
> by having more young members; replacing more than two members at one point
> will cause less replacements later; it increases the difficulty of finding
> new members.
> 
> The recent situation, with three TC members resigning, should not be 
> treated as exceptional in the context of this resolution. If it were to 
> happen again, I don't think that we should add one or two automatic 
> expirations to the three resignations.
> 
> This proposal differs from the original proposal by counting all 
> resignations and removals as part of the desirable "2 per year" replacement
> rate, so that the total number of replacements does not exceed two if only
> one or two younger members decide to resign.
> 
> This version of the proposal could even result in an internal TC 
> discussion: "OK, the Project wants two members to be replaced. Are there 
> members that feel like resigning now? Or should we just fallback to the 
> default of expiring the two most senior members?". I think that such a 
> discussion would be a healthy way for each TC member to evaluate its 
> status. The orignal proposal could have the detrimental effect of pushing
> inactive/demotivated members to stay on the TC until their expiration, to
> avoid causing additional churn.
> 
> Note that there are a few examples to compare the behaviour of the 2-S and
> 2-R proposals in <20141126142529.ga31...@xanadu.blop.info>.
> 
> Calling for seconds --- The DPL can propose general
> resolutions or GR amendments without seeking seconds. I initially wanted to
> waive that right, to only have this option on the ballot if there's
> sufficient interest from others, but the Secretary declined (in
> <20141124232153.ga17...@roeckx.be>).  I am therefore seeking seconds, and
> will withdraw this alternative proposal if it does not reach the required
> number of seconds by December 10th.
> 
> Thanks -- I would like to thank Stefano for organizing the discussion
> around this GR, and preparing the various versions of the resolution and
> amendments.
> 
> Lucas
> 

seconded

- -- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUfhgHAAoJEOs2Fx

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Anthony Towns]

On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote:
> The TC might be temporarily weakened by having more young members; 

While this is conceivable, I don't think it's even remotely likely in
practice -- there is a huge pool of brilliant people in Debian to draw
from, and the work undertaken by the tech ctte is not so different from
everything else in Debian that ctte newbies will be starting from scratch.

Likewise, past members of the ctte can still stick their noses in
(wanted or not), and the ctte can always informally invite people to
help out either for the sake of the help itself, or as a way of helping
people get experience in the role -- much like the DPL, the secretary,
ftpmaster, release team and DSA already have helpers and assistants [0].

I'm all for planning against all contingencies, I just think it's
important to recognise that, for Debian, worries about appointing novices
to the technical ctte are at the far end of hypothetical. Even if only
to remind the next batch of recruits that they're expected to be hitting
the same [1] standards of good judgement and whatnot as current and past
ctte members from day one of joining.

Cheers,
aj

[0] Multiple teams in Debian have "assistant" positions, and none of
them are called "minions"? Really? No "leader's lackeys", "DSA goon
squad", or "ftpmaster flunkies"? Total missed opportunity.

[1] (or better)


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141202035348.gb11...@master.debian.org

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Didier 'OdyX' Raboud]

Le lundi, 1 décembre 2014, 14.37:30 Lucas Nussbaum a écrit :
> I am hereby formally submitting an alternative proposal, between
> double-dashed lines below (formally it's an "amendment", but I don't
> expect Stefano to accept it, as we discussed it before). I am also
> calling for seconds (see below).
> 
> 
> ===
> The Constitution is amended as follows:
> 
> ---
> --- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
> +++ constitution.2-R.txt2014-11-24 10:24:42.109426386 +0100
> @@ -299,8 +299,22 @@
> Project Leader may appoint new member(s) until the number of
> members reaches 6, at intervals of at least one week per
> appointment.
> -5. If the Technical Committee and the Project Leader agree they may
> +5. A Developer is not eligible to be (re)appointed to the Technical
> +   Committee if they have been a member within the previous 12 months.
> +6. If the Technical Committee and the Project Leader agree they may
> remove or replace an existing member of the Technical Committee.
> +7. Term limit:
> + 1. On January 1st of each year the term of any Committee member
> +who has served more than 54 months (4.5 years) and who is one
> +of the N most senior members automatically expires. N is
> +defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of
> +former members of the Technical Committee who have resigned,
> +or been removed or replaced within the previous 12 months.
> + 2. A member of the Technical Committee is said to be more senior
> +than another if they were appointed earlier, or were appointed
> +at the same time and have been a member of the Debian Project
> +longer. In the event that a member has been appointed more
> +than once, only the most recent appointment is relevant.
>  
>6.3. Procedure
>  
> ---
> ===

Seconded.

OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Sam Hartman]

===
The Constitution is amended as follows:

---
--- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt2014-11-24 10:24:42.109426386 +0100
@@ -299,8 +299,22 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
-5. If the Technical Committee and the Project Leader agree they may
+5. A Developer is not eligible to be (re)appointed to the Technical
+   Committee if they have been a member within the previous 12 months.
+6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+7. Term limit:
+ 1. On January 1st of each year the term of any Committee member
+who has served more than 54 months (4.5 years) and who is one
+of the N most senior members automatically expires. N is
+defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of
+former members of the Technical Committee who have resigned,
+or been removed or replaced within the previous 12 months.
+ 2. A member of the Technical Committee is said to be more senior
+than another if they were appointed earlier, or were appointed
+at the same time and have been a member of the Debian Project
+longer. In the event that a member has been appointed more
+than once, only the most recent appointment is relevant.
 
   6.3. Procedure
 
---
===

Seconded.


pgppozd3LmLOc.pgp
Description: PGP signature

Alternative proposal (+call for seconds): Expire 2-R members every year

[Lucas Nussbaum]

[ Cross post -vote, -project ; M-F-T: to -vote ]

Hi,

I am hereby formally submitting an alternative proposal, between
double-dashed lines below (formally it's an "amendment", but I don't
expect Stefano to accept it, as we discussed it before). I am also
calling for seconds (see below).

===
The Constitution is amended as follows:

---
--- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-R.txt2014-11-24 10:24:42.109426386 +0100
@@ -299,8 +299,22 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
-5. If the Technical Committee and the Project Leader agree they may
+5. A Developer is not eligible to be (re)appointed to the Technical
+   Committee if they have been a member within the previous 12 months.
+6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+7. Term limit:
+ 1. On January 1st of each year the term of any Committee member
+who has served more than 54 months (4.5 years) and who is one
+of the N most senior members automatically expires. N is
+defined as 2-R (if R < 2) or 0 (if R >= 2). R is the number of
+former members of the Technical Committee who have resigned,
+or been removed or replaced within the previous 12 months.
+ 2. A member of the Technical Committee is said to be more senior
+than another if they were appointed earlier, or were appointed
+at the same time and have been a member of the Debian Project
+longer. In the event that a member has been appointed more
+than once, only the most recent appointment is relevant.
 
   6.3. Procedure
 
---
===

Rationale
-
First, I think that there is wide agreement that a more regular
turn-over among TC members would be a good thing. And both Stefano's
and this proposal aim at addressing this, by ensuring that at least 2
members of the TC are replaced every year.

However, too much turn-over, with more than 2 replacements at one point
of time, might have negative effects too. The TC might be temporarily
weakened by having more young members; replacing more than two members
at one point will cause less replacements later; it increases the
difficulty of finding new members.

The recent situation, with three TC members resigning, should not be
treated as exceptional in the context of this resolution. If it were to
happen again, I don't think that we should add one or two automatic
expirations to the three resignations.

This proposal differs from the original proposal by counting all
resignations and removals as part of the desirable "2 per year"
replacement rate, so that the total number of replacements does not
exceed two if only one or two younger members decide to resign.

This version of the proposal could even result in an internal TC
discussion: "OK, the Project wants two members to be replaced. Are there
members that feel like resigning now? Or should we just fallback to the
default of expiring the two most senior members?". I think that such a
discussion would be a healthy way for each TC member to evaluate its
status. The orignal proposal could have the detrimental effect of
pushing inactive/demotivated members to stay on the TC until their
expiration, to avoid causing additional churn.

Note that there are a few examples to compare the behaviour of the 2-S
and 2-R proposals in <20141126142529.ga31...@xanadu.blop.info>.

Calling for seconds
---
The DPL can propose general resolutions or GR amendments without seeking
seconds. I initially wanted to waive that right, to only have this
option on the ballot if there's sufficient interest from others, but the
Secretary declined (in <20141124232153.ga17...@roeckx.be>).  I am
therefore seeking seconds, and will withdraw this alternative proposal
if it does not reach the required number of seconds by December 10th.

Thanks
--
I would like to thank Stefano for organizing the discussion around this
GR, and preparing the various versions of the resolution and amendments.

Lucas


signature.asc
Description: Digital signature