Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.

[Stefano Zacchiroli]

On Mon, Mar 23, 2009 at 08:58:34PM +0100, Patrick Schoenfeld wrote:
> Stefano, actually I agree with its good intention. What I actually
> think is that we are kidding ourselves, because we already see whats
> needed, but don't go an active way of solving something which might
> be an issue. Instead we are acting only passive, with this note,
> with the best hope that someone will come and fix the problem.

It is true that this way of approaching the issue is passive, but you
should consider from whom that "warning" was coming from: the PTS
maintainers. Their role is maintaining the PTS and they output
warnings in good faith trying to do something useful. In this precise
setting they appeal to no authority or consensus stating that
"important" packages should be team maintained, what else can they do?
(using "they" because this precise suggestion predates my PTS
involvement)

So the "we" that already see the problem is not, potentially, as broad
as you see it. I surely consider myself as a part of that we, though.

> No, actually its ok if we have more then one team. Some of these
> packages are already team-maintained and possibly good. What I aimed
> at was a team that backups existing teams and pitches in where
> team-power is missing. A team that is always responsible for
> packages, which are otherwise only in the responsibility of single
> maintainers. Such a team would always be empowered to make uploads
> for these packages, without needing to escalate single issues to the
> CTTE or comply with waiting periods for NMUs.

Just to be clear on some details. I would be fine with both a single
team or multiple teams. However, I don't think it will be a good idea
to have official maintainers (teams or individual) and them something
else behind the scene stepping in only when something goes wrong or
when on a hurry uploads are needed. Teams work due to the
identification between declared maintainers (teams or individuals) and
the people actually doing the work. So, if there are people doing the
work they ought to be the maintainers/uploaders and vice-versa.

Turning this into a question for you: why the core-team you are
imagining as a backup should not become the actual maintenance team
instead of staying in the backup role? If the problem is not setting
aside the current maintainer, such maintainer should at least in the
beginning / interim be part of the new, forthcoming maintenance
team. I witnessed several maintenance transitions like the one I'm
imagining here, and it is IMO the best possible course of actions.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.

[Patrick Schoenfeld]

On Tue, Mar 24, 2009 at 09:46:31AM +0100, Stefano Zacchiroli wrote:
> On Mon, Mar 23, 2009 at 08:58:34PM +0100, Patrick Schoenfeld wrote:
> > Stefano, actually I agree with its good intention. What I actually
> > think is that we are kidding ourselves, because we already see whats
> > needed, but don't go an active way of solving something which might
> > be an issue. Instead we are acting only passive, with this note,
> > with the best hope that someone will come and fix the problem.
> 
> It is true that this way of approaching the issue is passive, but you
> should consider from whom that "warning" was coming from: the PTS
> maintainers. Their role is maintaining the PTS and they output
> warnings in good faith trying to do something useful. In this precise
> setting they appeal to no authority or consensus stating that
> "important" packages should be team maintained, what else can they do?
> (using "they" because this precise suggestion predates my PTS
> involvement)

Sure. Its no criticism targetted at the PTS maintainers. Its not even
criticism at all. Its just noteing that it got the attention of someone,
but it seems it didn't get the attention of the project. Which would
be quiet important, because those packages _are_ very important
for our project.

> So the "we" that already see the problem is not, potentially, as broad
> as you see it. I surely consider myself as a part of that we, though.

ACK.

> > No, actually its ok if we have more then one team. Some of these
> > packages are already team-maintained and possibly good. What I aimed
> > at was a team that backups existing teams and pitches in where
> > team-power is missing. A team that is always responsible for
> > packages, which are otherwise only in the responsibility of single
> > maintainers. Such a team would always be empowered to make uploads
> > for these packages, without needing to escalate single issues to the
> > CTTE or comply with waiting periods for NMUs.
> 
> Just to be clear on some details. I would be fine with both a single
> team or multiple teams. However, I don't think it will be a good idea
> to have official maintainers (teams or individual) and them something
> else behind the scene stepping in only when something goes wrong or
> when on a hurry uploads are needed. Teams work due to the
> identification between declared maintainers (teams or individuals) and
> the people actually doing the work. So, if there are people doing the
> work they ought to be the maintainers/uploaders and vice-versa.

Good point. There are two problems I see:
If we have a single core team, which is responsible for about 100
packages all alone, I guess we will quickly see those people beeing
overloaded. Second, the existing maintainers surely do some valueable
work and it would be a shame to take the work they do away from them.
I think such a new core-team would also be a good chance, to attract
some fresh blood. So how to proceed from here? It seems that the only
solution is...

> Turning this into a question for you: why the core-team you are
> imagining as a backup should not become the actual maintenance team
> instead of staying in the backup role?
.. to make the core-team the actual maintenance team and asking the
existing maintainers to join it. In the end I don't have a problem
if this team is somewhat bigger. What I think is valueable about such a
team is the effects that come from beeing part of a team and beeing
responsible. 

> If the problem is not setting
> aside the current maintainer, such maintainer should at least in the
> beginning / interim be part of the new, forthcoming maintenance
> team. I witnessed several maintenance transitions like the one I'm
> imagining here, and it is IMO the best possible course of actions.

Right.

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.

[Patrick Schoenfeld]

On Tue, Mar 24, 2009 at 01:15:00AM +, Steve McIntyre wrote:
> >What do you think about such a proposal?
> 
> I'd be quite worried about the blocking potential of such a move,
> actually. One of the reasons that Debian scales so well is that *most*
> of the work we do day-to-day does not depend on the work of a small
> core team. That means that we can continue to work independently and
> get the major package work done without having to co-ordinate
> everything and share decisions all the time. If we *did* end up with
> such a core team, then I'd bet money on them always being over-worked.
> It wouldn't start that way, but it would get there. Your people with
> "enough free time" quickly wouldn't have. :-)

To not repeat myself over and over again :-), did you see my mail
exchange with Stefano? It explains how I think how should be dealt with
it. 

> Of course, there are places where our work does need co-ordination,
> like before a release. And those are the places where we often end up
> needing large teams doing a lot of work just to do that co-ordination.

Well, coordination is the one thing. But something that is lacking in
Debian at all is serious Quality Assurance /while/ in a release cycle
(we have some basic QA during the freeze period, because the release
team needs to review every package that wants to get in, but that is..
not much and not enough). As we are dependent on the work of volunteers
we cannot solve this problem for the whole archive, but we should try to
solve it at least for the core tools every user is dependent on, which
is something were teams or a single big team would probably be a step in
the right direction.
 
> I'm much more convinced about encouraging people to set up individual
> teams for core packages, and then finding enough people to help cover
> the needs of those packages. More keen NMs are always good here...

Well the difference is only the number of persons. Which doesn't need to
be a difference at all. But I'm open to that as well, I just think we
should make it the default that those package are team-maintained and we
should have a fallback where those teams aren't setup on their own by
their individual maintainers.

Regards,
Patrick


signature.asc
Description: Digital signature

Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.

[Steve McIntyre]

On Tue, Mar 24, 2009 at 10:31:34AM +0100, Raphael Hertzog wrote:
>On Tue, 24 Mar 2009, Patrick Schoenfeld wrote:
>> existing maintainers to join it. In the end I don't have a problem
>> if this team is somewhat bigger. What I think is valueable about such a
>> team is the effects that come from beeing part of a team and beeing
>> responsible. 
>
>Given the workload on many core packages, I think it's not really
>reasonable to expect to have a big team responsible of many packages.
>I rather like the fact that we have smaller teams each dedicated to
>very few core packages. People can move from teams to teams and be part of
>multiple teams if needed.
>
>You can't have quality if you don't have 2-3 volunteers feeling personaly
>responsible for a given package.

Absolutely. Beyond a certain size, a team is much more likely to fall
back to "somebody else will do it".

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.

[Raphael Hertzog]

On Tue, 24 Mar 2009, Patrick Schoenfeld wrote:
> > Turning this into a question for you: why the core-team you are
> > imagining as a backup should not become the actual maintenance team
> > instead of staying in the backup role?
> .. to make the core-team the actual maintenance team and asking the
> existing maintainers to join it. In the end I don't have a problem
> if this team is somewhat bigger. What I think is valueable about such a
> team is the effects that come from beeing part of a team and beeing
> responsible. 

Given the workload on many core packages, I think it's not really
reasonable to expect to have a big team responsible of many packages.
I rather like the fact that we have smaller teams each dedicated to
very few core packages. People can move from teams to teams and be part of
multiple teams if needed.

You can't have quality if you don't have 2-3 volunteers feeling personaly
responsible for a given package.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Q to Steve and Luk: sharing of workload?

[Lucas Nussbaum]

Dear Steve and Luk,

So, you are running in tandem. How do you plan to organize the sharing
of the DPL workload?

Will Steve be The DPL, with Luk only helping on some matters? Or will it
be more like 50/50? For example, who will receive lea...@debian.org?

Luk, you are already a very busy DD, with your Release Manager hat, and
your work inside the buildd team, and SPI. Which of those roles will you
temporarily give up during the DPL term? Your role of Release Manager is
very important for the project, and many DD might not want to lose a RM:
it's a very demanding and time-consuming position, and we might have
problems finding another victim. Can you convince us that the Release
team can survive without you?

- Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Amendment] Reaffirm the GR process

[Bill Allombert]

On Mon, Mar 23, 2009 at 04:44:18PM -0700, Lucas Nussbaum wrote:
> On 24/03/09 at 00:29 +0100, Frans Pop wrote:
> > > PROPOSAL START
> > > ===
> > > General Resolutions are an important framework within the Debian
> > > Project, which have served us well since the first GR vote in 2003,
> > > with 804 developers, nearly has much as today slightly over 1000
> > > developers.
> > >
> > > Therefore the Debian project reaffirms its attachement to the
> > > constitution and the current General Resolutions process.
> > > ===
> > > PROPOSAL END
> > 
> > IMO this deserves to be an explicit option on the ballot. It makes for a 
> > much clearer choice than having "further discussion" fulfill that role.
> > 
> > OTOH, I think the text of the amendment could be improved as the GR from 
> > Ganneff does not really change the GR _process_ but only the requirements 
> > regarding nr. of seconders.
> > 
> > I'd second a somewhat revised text, for example:
> >Therefore the Debian project confirms the current requirements for
> >the sponsoring (seconding) of GR proposals or amendments, and for
> >overruling of delegates.
> > 
> > I'll not comment on the accuracy of the first para.
> 
> Indeed, the numbers are clearly questionable. Maybe it shouldn't include
> them, and also provide a sketch of justification for refusing the
> change?

Well the numbers are the one published on vote.debian.org. Everyone
can check that.

> Something like:
> <---
> General Resolutions are an important framework within the Debian
> Project, which have served us well for years. While over those years,
> some problems have arised during the discussion and/or voting of some
> resolutions, there is no evidence that changing the number of sponsors
> (seconds) for GR proposals or amendments will help solve those problems.
> Instead, by making it harder to propose general resolutions or
> amendments, it might make it harder to improve imperfect resolutions, or
> to add valuable options to a ballot.
> --->

I am quite ready to accept that my amendment when hastily drafted and far
from perfect. Please propose a better amendment and I will gladly rescind
mine.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.

[Stefano Zacchiroli]

On Tue, Mar 24, 2009 at 10:21:23AM +0100, Patrick Schoenfeld wrote:
> Sure. Its no criticism targetted at the PTS maintainers. Its not
> even criticism at all. Its just noteing that it got the attention of
> someone, but it seems it didn't get the attention of the
> project. Which would be quiet important, because those packages
> _are_ very important for our project.

Agreed; BTW, I did not interpret that as criticism at all.  So, to
summarize, the PTS was *a* tentative to get the message through which,
as you observed, was not enough to reach the goal (assuming the goal
is agreed upon by the project).

> I think such a new core-team would also be a good chance, to attract
> some fresh blood. So how to proceed from here? It seems that the
> only solution is...

> .. to make the core-team the actual maintenance team and asking the
> existing maintainers to join it. In the end I don't have a problem
> if this team is somewhat bigger.

For what is worth, that's exactly the experience I had with my
participation in the maintenance of popular packages (even though not
as important as the one we are mentioning here).

1) in the beginning there was the maintainer
2) then the maintainer get overloaded and asked for help
3) then a team was formed federating together some of the people who
   replied
4) then, with time, the old maintainer faded away and a new structure
   (possibly with tasks and leadership) emerged in the new team

That's IME the best possible road from sole and overloaded maintainers
to sane team maintenance. As you observe in another post, the delicate
part is of course "encouraging" (2) when the sole maintainer is
overloaded but not willing to admit it.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Question for DPL Candidates: Debian $$$

[MJ Ray]

Stefano Zacchiroli  wrote:
> On Mon, Mar 23, 2009 at 12:43:06PM +, MJ Ray wrote:
> > paying grants to other charities to evaluate debian,
>
> What does this mean? Paying someone to "evaluate" debian? I don't get
> this ...

As I understand it, charities currently pick their operating system by
either doing an independent evaluation (an old guide of that sort of
style from when I last worked for a non-profit is at
http://www.volresource.org.uk/swit/select.htm ) or by buying from an
approved list like http://www.ctxchange.org/directory/30

Use of debian seems to be limited because it isn't on any approved
lists and charties can't get funding for an independent evaluation at
the moment.  Would you support using donations to fund one or both of
those?

> > to adapt it to meet their needs and deploy it,
>
> Who will be payed to do the development and deployment? [...]

Whoever the charities would select.  I think it's not up to me because
I have a conflict of interest.

> > or to hold meetings to do that?
>
> That, on the contrary, is perfectly reasonable and I will be all for
> that.

How would you like that to work?

> > I was at a meeting for local voluntary and community infrastructure
> > organisations and the most-mentioned reason for not considering
> > debian seemed to be a lack of resources.  Meanwhile, the debian
> > project seems to have surplus resources.  This seems a bit of a daft
> > situation.
>
> Please expand this argument. Who was looking for resources and which
> kind of resources where they looking for?

Some attendees at the recent NAVCA.org.uk event http://bit.ly/EGL5
seemed to be saying that they didn't consider free and open source
software because of a lack of resources to get the decision-makers to
meet/work on such things. They weren't looking for resources, but they
didn't know that people donated money to organisations for the general
promotion of debian. I think that lack of awareness among non-profits
is something that debian's money could help to address, if there's
enough for the forseeable in-project needs.

I'm undecided about the most effective kind of resources, but there
only seems point investigating further if a general aim of targetted
debian promotion to NPOs would be funded.

Does that explain it and do the candidates think surplus donations
could be used to help NPOs to consider debian in some way?

Regards,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: All candidates: Membership procedures

[Stefano Zacchiroli]

On Sat, Mar 21, 2009 at 11:34:57AM +0200, Lars Wirzenius wrote:
> What's your opinion on membership procedures?
> 
> Last year there were some rough proposals for how to change the
> membership procedures. It started with Joerg's proposal, but other
> people suggested their own kinds of changes, including me. I feel
> that my approach and Joerg's are pretty much diametrically
> opposed. What's your opinion? Do you feel the current NM process
> works well and almost always selects for the kind of people that are
> really great for Debian?  Would some other kind of process work
> better? What kind of membership process would you like to see in
> Debian in, say, a year from now?

Heya, here I am after having re-read your proposal (which I take, from
your reply, has not been significantly affected by the resulting
discussion).

You ask me to dream, ... let's dream.
I dream of:
- an NM process where the enthusiasm of applicants does not encounter
  frustrations due to delays they cannot understand
- a project in which not only technical skills matter for being able
  to vote
- membership principles which acknowledge the level of commitment
  contributors are willing to offer: if in the beginning you are
  willing only to work on X, you will be able to work on X, getting
  from the project the credit and the recognition you deserve; if you
  are willing to do more you will get more tools to do that and more
  credit for your achievements
- a do-ocratic project in which everybody is free to temporarily
  leave when real life strikes back, with no shame, and come back
  whenever he/she wants and has time again to contribute
- a project where core teams, on the work of which the whole project
  depends, exhibit no concentration of powers. That is:
  * job descriptions are crystal clear,
  * "recruiting" procedures are as clear and always open to new
applicants,
  * team members are on the order of 10 people rather then 2 (no
problem if one is *the* leader, but the others should be able to
backup him/her up in case of emergencies),
  * there is no overlapping of people among the core teams,
  * there is no bureaucratic bottleneck imposed by the fact that core
teams are under-staffed.


Now, regarding the two proposals. Joerg proposal [1] was an
_evolutionary_ one starting from the status quo, introducing a new
class of non-technical contributors, and also meant to fix (as I
interpreted it back then) some of the technical oddities of the
current DM/DD duality. The main problem of that proposal has been in
the way it has been pushed; a way which has been refused [3] for that
reason.

Your proposal [2] touched more subjects which IMO warrant separate
discussions. I'll comment on the main topics.

- Project membership should expire: full ACK.

  The way you propose to achieve that (putting into use the right to
  vote) is not the only possible way, uploads are another, but I agree
  with the principle, the rest are details at this point.

- All members get both voting and upload rights: not sure.

  I've no strong objection, but I've the impression that there are out
  there contributors which couldn't care less about upload rights; if
  this is so I don't see why giving them that (if you want: don't fix
  what is not broken). Same goes in the other direction.

- Expulsion via GR. Yes, makes sense.

  It is a scenario rare enough where we don't need to appeal to
  representative democracy to handle it, as we currently do with the
  over-engineered expulsion procedure.

- Join via consensus: agreed in principle, worries about practical
  applicability.

  We have a lot of sub-areas in Debian, areas which do not necessarily
  know each other. NM are often willing to join because they are
  interested in a single area. Asking for project consensus sounds me
  a bit odd. E.g.: I don't know what I can say about the acceptance in
  Debian of a guy interested in working on translations or Java
  package maintenance, while I can have a lot to say about the
  acceptance of a guy interested in maintaining OCaml packages or the
  PTS. I would be much more in favor of join via a philosophy and
  procedure and then delegate technical skill review to the teams the
  NM is planning to work in in the beginning (which would also give
  some guaranteed of social interaction ability).

- Keyring maintenance: agreed with what you wrote, which however in my
  mind settled down a bit differently "let's enlarge the keyring
  maintenance team, and use jetring". This, however, is an example of
  a point which deserves IMO a separate discussion, asking keyring
  maintainers for comments.


A final remark. Choices like the above one need project ultra-wide
discussions and clear decisions via GRs. What I will do as DPL, if the
time come, is just to ensure that we clarify the available options
(yours being one of them) and have a vote on them; the DPL should do
no more than that.

Cheers.

PS Yes, I know you did not ask for explicit

Re: Question for DPL Candidates: Debian $$$

[Stefano Zacchiroli]

On Tue, Mar 24, 2009 at 01:58:02PM +, MJ Ray wrote:
> As I understand it, charities currently pick their operating system
> by either doing an independent evaluation (an old guide of that sort
> of style from when I last worked for a non-profit is at
> http://www.volresource.org.uk/swit/select.htm ) or by buying from an
> approved list like http://www.ctxchange.org/directory/30
> 
> Use of debian seems to be limited because it isn't on any approved
> lists and charties can't get funding for an independent evaluation
> at the moment.  Would you support using donations to fund one or
> both of those?

In principle, yes.

Practically aspects that I would evaluate before taking the final
decision are things like: how much it will cost (obviously), how many
charities consider that list, etc etc. Plain old cost-benefit analysis
if you want.

> > Who will be payed to do the development and deployment? [...]
> 
> Whoever the charities would select.  I think it's not up to me
> because I have a conflict of interest.

That was one problem I had in mind. The other I've mentioned stand:
first we should try to look for non-payware ways of achieving the
result. Then we should consider paying someone. A topic like this one
would surely be one on which I would first look for agreement among
DDs before giving moneys away though.

> > That, on the contrary, is perfectly reasonable and I will be all
> > for that.
> 
> How would you like that to work?

Well, easy. First I would like to see a team formed "inside" Debian
(a-la alioth project) contributing energies to the goal. Then the team
will look for Debian money to support a meeting like any other team,
in my vision, can do. You tell me how much money the meeting will
cost, how much you are _unable_ to collect [1], and I will evaluate
and give the needed money.

> Some attendees at the recent NAVCA.org.uk event http://bit.ly/EGL5
> seemed to be saying that they didn't consider free and open source
> software because of a lack of resources to get the decision-makers
> to meet/work on such things. They weren't looking for resources, but
> they didn't know that people donated money to organisations for the
> general promotion of debian. I think that lack of awareness among
> non-profits is something that debian's money could help to address,
> if there's enough for the forseeable in-project needs.

It seems to me that the solution to this kind of problem is not money
per se, but rather making known that we do have money and how that
money flow in/out Debian. As I've said elsewhere in this thread, we
should make all that more transparent. Apparently it will have
interesting side-effects also for your use case.

> I'm undecided about the most effective kind of resources, but there
> only seems point investigating further if a general aim of targetted
> debian promotion to NPOs would be funded.
> 
> Does that explain it and do the candidates think surplus donations
> could be used to help NPOs to consider debian in some way?

To summarize: yes in principle, details should be however considered
case by case, once the "kind of resources" gets clearer.

Cheers.

[1] one thing is making possible things that were impossible without
money; another one is wasting money, e.g., by paying hotel bills
for 3-people meetings that can happen in the home of one of the 3
by paying train tickets to the others

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Amendment: Enhance requirements for General resolutions

[Colin Tuckley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joerg Jaspert wrote:

> and here is the promised amendment which will require a maximum of
> floor(Q) developers to second a GR.
> 
> PROPOSAL START
> 
> General Resolutions are an important framework within the Debian
> Project. Yet, in a project the size of Debian, the current requirements
> to initiate one are too small.
> 
> Therefore the Debian project resolves that
>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(Q). [see §4.2(1)]
>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
> as well as resolutions against a shortening of discussion/voting
> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
> developers to sponsor the resolution.
>  c) the definition of K gets erased from the constitution. [§4.2(7)]
> 
> (Numbers in brackets are references to sections in the constitution).
> 
> PROPOSAL END

I second this proposal.

Colin

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

"Waiter, there's no fly in my soup!" -- Kermit the frog
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknJFpUACgkQj2OPlhswRc5TswCfd0IRAGLfg2+eChX4FBF06X2D
rqkAn1OGPrcY3Bey/7+dBYGB9wJg4OuV
=ZowI
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Q to Steve and Luk: sharing of workload?

[Luk Claes]

Lucas Nussbaum wrote:
> Dear Steve and Luk,

Hi Lucas

> So, you are running in tandem. How do you plan to organize the sharing
> of the DPL workload?

I think we'll try to spread the workload depending on the circumstances
of the moment.

> Will Steve be The DPL, with Luk only helping on some matters? Or will it
> be more like 50/50? For example, who will receive lea...@debian.org?

We will both receive lea...@debian.org and will divide the tasks between
us. Of course we will discuss with each other for important decisions
and about who does what including feedback about what has been done.

Steve will of course have the last word as he is the official DPL. So he
certainly will correct anything I misrepresented above :-)

> Luk, you are already a very busy DD, with your Release Manager hat, and
> your work inside the buildd team, and SPI. Which of those roles will you
> temporarily give up during the DPL term? Your role of Release Manager is
> very important for the project, and many DD might not want to lose a RM:
> it's a very demanding and time-consuming position, and we might have
> problems finding another victim. Can you convince us that the Release
> team can survive without you?

I think I'll be less active on most of them, though that does not mean
the members of the mentioned teams have to lose me :-) I certainly will
have to delegate more and find more people willing to do the 'ground
work', though I think that's a good thing. Currently the RMs are doing a
lot of day to day tasks, having more delegation would mean they could
focus more on the communication and management both in the Release Team
(and for me also elsewhere which is in line with the role of DPL
assistant AFAICS).

Btw, I'm certainly interested to know who is interested in day-to-day QA
& release tasks, in one of my packages, in buildd maintenance or in
taking over other things I do, to relieve my workload. Please contact me
in private and we'll try to work something out.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Proposal: Enhance requirements for General resolutions

[Don Armstrong]

On Sat, 21 Mar 2009, Don Armstrong wrote:
> I'm going to make suggestions for changes to both proposals here; just
> change 2*floor(Q) to floor(Q) for the second alternative. Note that
> I've switched from floor(2Q) to 2*floor(Q); this changes the majority
> requirements from 31 to 30, which is what the extended rationale said
> as an example.

Truncated wdiff output that implements this is below, diff attached.

4.2. Procedure


  
The Developers follow the Standard Resolution Procedure, below. A
resolution or amendment is introduced if proposed by any Developer and
sponsored by at least [-K-] {+2*floor(Q)+} other Developers, or if proposed 
by
the Project Leader or the Technical Committee.
  

  
Delaying a decision by the Project Leader or their Delegate:


  If the Project Leader or their Delegate, or the Technical
  Committee, has made a decision, then Developers can override them
  by passing a resolution to do so; see s4.1(3).

  [-If such-]

  {+When+} a resolution [-is-] {+has been+} sponsored by at least 
[-2K-] {+floor(Q)+} Developers,
  or if it is proposed by the Technical Committee, the resolution puts
  the decision immediately on [-hold (provided-] {+hold, provided+} that 
resolution itself says [-so).

  If the original decision was to change a discussion period or
  a voting period, or the resolution is to override the Technical
  Committee, then only K Developers need to sponsor the resolution
  to be able to-]
  {+that it will+} put the decision [-immediately-] on [-hold.-] 
{+hold immediately.+}

[...]

  
Q is half of the square root of the number of current Developers.  [-K-]
{+floor(Q)+} is [-Q-] {+the nearest integer less than+} or [-5, whichever-] 
{+equal to Q. 2*floor(Q)+} is [-the smaller.-]
{+two times floor(Q).+} Q [-and K-] need not be [-integers-] {+an integer+} 
and [-are-] {+is+} not rounded.
  




Don Armstrong

-- 
Religion is religion, however you wrap it, and like Quell says, a
preoccupation with the next world clearly signals an inability to cope
credibly with this one.
 -- Richard K. Morgan "Broken Angels" p65

http://www.donarmstrong.com  http://rzlab.ucr.edu
--- gr_mod_second.wml.orig	2009-03-22 17:17:38.0 -0700
+++ gr_mod_second.wml.new	2009-03-22 17:25:46.0 -0700
@@ -2,10 +2,10 @@
 
 
   
-The Developers follow the Standard Resolution Procedure, below.
-A resolution or amendment is introduced if proposed by any
-Developer and sponsored by at least K other Developers, or if
-proposed by the Project Leader or the Technical Committee.
+The Developers follow the Standard Resolution Procedure, below. A
+resolution or amendment is introduced if proposed by any Developer and
+sponsored by at least 2*floor(Q) other Developers, or if proposed by
+the Project Leader or the Technical Committee.
   
 
   
@@ -16,15 +16,10 @@
   Committee, has made a decision, then Developers can override them
   by passing a resolution to do so; see s4.1(3).
 
-  If such a resolution is sponsored by at least 2K Developers,
-  or if it is proposed by the Technical Committee, the resolution
-  puts the decision immediately on hold (provided that resolution
-  itself says so).
-
-  If the original decision was to change a discussion period or
-  a voting period, or the resolution is to override the Technical
-  Committee, then only K Developers need to sponsor the resolution
-  to be able to put the decision immediately on hold.
+  When a resolution has been sponsored by at least floor(Q) Developers,
+  or if it is proposed by the Technical Committee, the resolution puts
+  the decision immediately on hold, provided that resolution itself says
+  that it will put the decision on hold immediately.
 
   If the decision is put on hold, an immediate vote is held to
   determine whether the decision will stand until the full vote on
@@ -68,8 +63,8 @@
   
 
   
-Q is half of the square root of the number of current
-Developers.  K is Q or 5, whichever is the smaller.  Q and K need not
-be integers and are not rounded.
+Q is half of the square root of the number of current Developers.
+floor(Q) is the nearest integer less than or equal to Q. 2*floor(Q) is
+two times floor(Q). Q need not be an integer and is not rounded.
   
 

Re: What will improve Debian most?

[Raphael Hertzog]

On Tue, 24 Mar 2009, Anthony Towns wrote:
> Over the next twelve months, what single development/activity/project
> is going to improve Debian's value the most? By how much? How will
> you be involved?

Having such a discussion is really interesting, I would not limit it
to -vote and DPL candidates. We should re-raise the topic on -devel and
let all contributors share their big plans for the next year. Going
further we could even have an IdeaTorrent setup (à la
brainstorm.ubuntu.com) where we could all register our
projects/ideas/plans for Debian and have other Debian contributors rate
the ideas. (We could also have a variant open to all users)

http://www.ideatorrent.org

My plans/ideas are the following:

 - Global switch to new source format 3.0 (quilt) + drive DEP3 to
   standardize the meta-information on debian/patches/*

   - Goal: uniformize most packages around a single patch management
 system. This makes it easier to occasional contributors, they
 can help by learning a single patch management system.
   - Goal: better collaboration with upstream and other distributions
 because all Debian-specific changes are in separate patches that
 will be documented in a standard format (lintian warning will require
 that). Get rid of undocumented Debian-specific change in .diff.gz.

 - dpkg-vendor tool that can be used in source packages

   - Goal: facilitate cooperation with derivatives by having a common
 source package for multiple distributions

 - Offer some official interface in dpkg-dev to drive a package build
   within a VCS (source package created from the VCS directly too).

   - Goal: making it easier for occasional contributors so that they don't
 have to learn another *-buildpackage tool each time that they hack on
 another package.

 - Create a debian-love desktop application that would handhold users into
   becoming new contributors. The user would select "contributions
   scenarios" that are of interest for him and when he has some time to
   spend on Debian, he would run one of the scenarios suggested by
   the application ("translate .po file for package X", "try to reproduce
   bug X", "suggest debtags for package X", "add screenshot for
   application X") with the help of some wizard-like interface.
   
   It would make use of all the information available locally and on the
   net. You can combine the information that application X is used
   regularly and the fact that the bug #123 reported against this
   application (same version as the user!) is tagged unreproducible to ask
   the user to help reproduce the problem. Possibilities are very broad…

   - Goal: recruit more contributors, spread knowledge about our processes
 in a entertaining way, make bug management more effective (tagging
 bugs unreproducible would drive the attention of more users to
 increase the chance that someone can reproduce it), etc.

 - Drive DEP2 to define a system that allows us to monitor more
   effectively and precisely the maintenance status of all packages.
   http://lists.debian.org/debian-qa/2008/12/msg00046.html

   - Goal: ensure we always have up-to-date information on maintenance
 status of packages so that new contributors can be redirected where
 their help will be welcome, useful and not ignored.


Not sure all of this fit in a single year… I would not mind if someone
else would be interested to create the debian-love application. :)

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Amendment] Reaffirm the GR process

[Robert Millan]

On Mon, Mar 23, 2009 at 11:42:40PM +0100, Bill Allombert wrote:
> Hello developers,
> 
> I am hereby proposing the amendement below to the General resolution
> entitled "Enhance requirements for General resolutions".
> 
> PROPOSAL START
> 
> General Resolutions are an important framework within the Debian
> Project, which have served us well since the first GR vote in 2003,
> with 804 developers, nearly has much as today slightly over 1000
> developers.
> 
> Therefore the Debian project reaffirms its attachement to the constitution
> and the current General Resolutions process.
> 
> PROPOSAL END

Seconded.


I'd also like to complain about the title text of the initial GR.  It is
clearly manipulative, as it pretends to be merely describing the proposed
changes when in fact it is asserting an opinion.  I hope the Secretary
will fix this.

And if that's too much to ask, then I hope voters will read carefuly and
won't fall for such an easy trick.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


signature.asc
Description: Digital signature

Re: [Amendment] Reaffirm the GR process

[Michael Banck]

On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote:
> I'd also like to complain about the title text of the initial GR.  It is
> clearly manipulative, as it pretends to be merely describing the proposed
> changes when in fact it is asserting an opinion.  I hope the Secretary
> will fix this.

Hear, hear.


Michael


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Proposal: Enhance requirements for General resolutions

[Kurt Roeckx]

On Mon, Mar 23, 2009 at 11:51:37PM +, Steve McIntyre wrote:
> On Sat, Mar 21, 2009 at 03:47:57PM +0100, Joerg Jaspert wrote:
> >
> >PROPOSAL START
> >
> >General Resolutions are an important framework within the Debian
> >Project. Yet, in a project the size of Debian, the current requirements
> >to initiate one are too small.
> >
> >Therefore the Debian project resolves that
> > a) The constitution gets changed to not require K developers to sponsor
> >a resolution, but floor(2Q). [see §4.2(1)]
> > b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
> >as well as resolutions against a shortening of discussion/voting
> >period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
> >developers to sponsor the resolution.
> > c) the definition of K gets erased from the constitution. [§4.2(7)]
> >
> >(Numbers in brackets are references to sections in the constitution).
> >
> >PROPOSAL END
> 
> Assuming that you'll provide explicit diffs for the constitution:
> 
> Seconded.

I'm not really sure how to interprete this.  Does this mean you'll
only second it after he changes the proposal to include the diff?


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Amendment] Reaffirm the GR process

[Kurt Roeckx]

On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote:
> 
> I'd also like to complain about the title text of the initial GR.  It is
> clearly manipulative, as it pretends to be merely describing the proposed
> changes when in fact it is asserting an opinion.  I hope the Secretary
> will fix this.

I think the title is also not the best one and just used Joerg's
title.

What about:
General Resolution sponsorship requirements


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[Amendment] Reaffirm current requirements for GR sponsoring

[Lucas Nussbaum]

Hi,

I am hereby proposing the amendment below to the general resolution
entitled "Enhance requirements for General resolutions".

PROPOSAL START
=
General Resolutions are an important framework within the Debian
Project. While over those years, some problems have arised during the
discussion and/or voting of some resolutions, there is no evidence that
changing the number of sponsors (seconds) for GR proposals or amendments
will help solve those problems.  Instead, by making it harder to propose
general resolutions or amendments, it might make it harder to improve
imperfect resolutions, or to add valuable options to a ballot.

Therefore the Debian project reaffirms the current requirements for the
sponsoring (seconding) of GR proposals or amendments, and for overruling
of delegates.
=
PROPOSAL END

This is an attempt to provide a rather neutral "keep things as is"
option. I believe that we need to provide basic information about why we
are voting this, hence the first paragraph, which, I hope, is vague
enough ("might", etc) not to prevent anyone from sponsoring or voting
for this option.

I hope that Bill Allombert will rescind his own amendment. If he chooses
to keep it, I might rescind this one instead (we don't need two "keep
things as is" options on the ballot).

Also, it would be great if the title of the GR was "enhanced" with
s/Enhance/Change/.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: [Amendment] Reaffirm the GR process

[Robert Millan]

On Tue, Mar 24, 2009 at 11:52:22PM +0100, Kurt Roeckx wrote:
> On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote:
> > 
> > I'd also like to complain about the title text of the initial GR.  It is
> > clearly manipulative, as it pretends to be merely describing the proposed
> > changes when in fact it is asserting an opinion.  I hope the Secretary
> > will fix this.
> 
> I think the title is also not the best one and just used Joerg's
> title.
> 
> What about:
> General Resolution sponsorship requirements

Sounds good to me.

Thank you

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: All candidates: Membership procedures

[Julien Cristau]

On Tue, 2009-03-24 at 00:56 +, Steve McIntyre wrote:
> In terms of the right to vote in Debian, I'm thinking that does need
> to be earned by an obvious long-term commitment to the project. Maybe
> a minimum count of packages uploaded, or strings translated, or web
> pages written over a 1-year period would work for that.

The 'minimum count of packages uploaded' seems contradictory with the
wish to have people join existing teams.  There's a lot of work that we
need done and that doesn't involve uploading packages.  Not that I have
a better metric, mind you.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Amendment] Reaffirm current requirements for GR sponsoring

[Frans Pop]

Lucas Nussbaum wrote:
> PROPOSAL START
> =
> General Resolutions are an important framework within the Debian
> Project. While over those years, some problems have arised during the
> discussion and/or voting of some resolutions, there is no evidence that
> changing the number of sponsors (seconds) for GR proposals or amendments
> will help solve those problems.  Instead, by making it harder to propose
> general resolutions or amendments, it might make it harder to improve
> imperfect resolutions, or to add valuable options to a ballot.
> 
> Therefore the Debian project reaffirms the current requirements for the
> sponsoring (seconding) of GR proposals or amendments, and for overruling
> of delegates.
> =
> PROPOSAL END

Seconded.
 
> This is an attempt to provide a rather neutral "keep things as is"
> option.

Thanks Lucas.

> Also, it would be great if the title of the GR was "enhanced" with
> s/Enhance/Change/.

Agreed. And the same for the ballot options proposed in the initial mail.


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

Re: [Amendment] Reaffirm current requirements for GR sponsoring

[Lucas Nussbaum]

On 24/03/09 at 16:10 -0700, Lucas Nussbaum wrote:
> Hi,
> 
> I am hereby proposing the amendment below to the general resolution
> entitled "Enhance requirements for General resolutions".
> 
> PROPOSAL START
> =
> General Resolutions are an important framework within the Debian
> Project. While over those years, some problems have arised during the
> discussion and/or voting of some resolutions, there is no evidence that
> changing the number of sponsors (seconds) for GR proposals or amendments
> will help solve those problems.  Instead, by making it harder to propose
> general resolutions or amendments, it might make it harder to improve
> imperfect resolutions, or to add valuable options to a ballot.
> 
> Therefore the Debian project reaffirms the current requirements for the
> sponsoring (seconding) of GR proposals or amendments, and for overruling
> of delegates.
> =
> PROPOSAL END

Since nobody sponsored it yet, I'm amending it to fix:
s/arised/arisen/
s/those years/the years/

PROPOSAL START
=
General Resolutions are an important framework within the Debian
Project. While over the years, some problems have arisen during the
discussion and/or voting of some resolutions, there is no evidence that
changing the number of sponsors (seconds) for GR proposals or amendments
will help solve those problems.  Instead, by making it harder to propose
general resolutions or amendments, it might make it harder to improve
imperfect resolutions, or to add valuable options to a ballot.

Therefore the Debian project reaffirms the current requirements for the
sponsoring (seconding) of GR proposals or amendments, and for overruling
of delegates.
=
PROPOSAL END

Maybe we should make it mandatory to ask for review from a native
speaker before submitting a GR or an amendment? :-)

> This is an attempt to provide a rather neutral "keep things as is"
> option. I believe that we need to provide basic information about why we
> are voting this, hence the first paragraph, which, I hope, is vague
> enough ("might", etc) not to prevent anyone from sponsoring or voting
> for this option.
> 
> I hope that Bill Allombert will rescind his own amendment. If he chooses
> to keep it, I might rescind this one instead (we don't need two "keep
> things as is" options on the ballot).
> 
> Also, it would be great if the title of the GR was "enhanced" with
> s/Enhance/Change/.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: [Amendment] Reaffirm current requirements for GR sponsoring

[Steve Langasek]

On Tue, Mar 24, 2009 at 04:49:54PM -0700, Lucas Nussbaum wrote:
> Since nobody sponsored it yet,

Actually, someone did, but:

> I'm amending it to fix:
> s/arised/arisen/
> s/those years/the years/

Under A.1.6, you can fix spelling and grammar without having to re-solicit
seconds.

-- 
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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Amendment] Reaffirm current requirements for GR sponsoring

[Kurt Roeckx]

On Tue, Mar 24, 2009 at 04:49:54PM -0700, Lucas Nussbaum wrote:
> On 24/03/09 at 16:10 -0700, Lucas Nussbaum wrote:
> > Hi,
> > 
> > I am hereby proposing the amendment below to the general resolution
> > entitled "Enhance requirements for General resolutions".
> > 
> > PROPOSAL START
> > =
> > General Resolutions are an important framework within the Debian
> > Project. While over those years, some problems have arised during the
> > discussion and/or voting of some resolutions, there is no evidence that
> > changing the number of sponsors (seconds) for GR proposals or amendments
> > will help solve those problems.  Instead, by making it harder to propose
> > general resolutions or amendments, it might make it harder to improve
> > imperfect resolutions, or to add valuable options to a ballot.
> > 
> > Therefore the Debian project reaffirms the current requirements for the
> > sponsoring (seconding) of GR proposals or amendments, and for overruling
> > of delegates.
> > =
> > PROPOSAL END
> 
> Since nobody sponsored it yet, I'm amending it to fix:
> s/arised/arisen/
> s/those years/the years/

The constitution even covers such changes: A.1.:
6. The proposer of a resolution may make changes to correct minor
   errors (for example, typographical errors or inconsistencies) or
   changes which do not alter the meaning, providing noone objects
   within 24 hours. In this case the minimum discussion period is not
   restarted.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: All candidates: Membership procedures

[Steve McIntyre]

On Wed, Mar 25, 2009 at 12:47:09AM +0100, Julien Cristau wrote:
>On Tue, 2009-03-24 at 00:56 +, Steve McIntyre wrote:
>> In terms of the right to vote in Debian, I'm thinking that does need
>> to be earned by an obvious long-term commitment to the project. Maybe
>> a minimum count of packages uploaded, or strings translated, or web
>> pages written over a 1-year period would work for that.
>
>The 'minimum count of packages uploaded' seems contradictory with the
>wish to have people join existing teams.  There's a lot of work that we
>need done and that doesn't involve uploading packages.  Not that I have
>a better metric, mind you.

Yup, I agree. It's not an easy thing to measure, but we need to come
up with something.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [dissenting]: Proposal: Enhance requirements for General resolutions

[Gunnar Wolf]

Bill Allombert dijo [Sun, Mar 22, 2009 at 11:53:02PM +0100]:
> This theory does not match the project history in any way. 
> vote.debian.org details all the GR which garnered sufficient
> level of support to be valid to be called for vote:
> 
> The first GR was passed in June 2003 and there were 804 developers.
> The last GR was passed in November 2008 and there were 1018 developers.
> 
> So the number of developers did not significantly increase as far as
> GR are concerned.
> (...)
> To set an example, are you willing to refrain to call for vote this GR until
> you get at least 30 seconds ?
> (...)
> I am afraid this GR will be inefficient to reach its objective (which
> I disapprove of):
> 
> 1) It does not limit the number of GR proposal which will be made, only
> the number that will be callable for vote.
> 
> 2) This will reduce the standard for seconding GR proposals.
> 
> 3) It can be worked around by a set of 25 developers that would just
> seconds any GR proposal made, even if they plan to vote against.

Humh... Maybe this could be solved by having two numbers for two
different things instead of only one.

Maybe a higher number of developers than the 5 needed today should be
pursued to bring a topic to GR. However, to push for each of the
topic's possible resolutions, 5 would be still enough.

Very often, many people with heavily dissenting points of view will
only agree on the need to hold a GR. So, there we have enough people
(although 30 still seems too high for me - Specially given that only a
portion of the active DDs is also active in the lists and
decision-taking processes). The possible options (amendments) to be
voted are alternative ways out of the situation, and could be
satisfied with probably the current five seconders. 

And FWIW, just not to forget the point: Several months ago, when this
thread was last mentioned, I expressed my opinion on that _seconding_
a ballot should not be taken as _supporting_ the ballot - It might
just be recognized as an important viewpoint to take into
consideration, even for a particular DD who is against it.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgpquG13tPvwF.pgp
Description: PGP signature

Re: [dissenting]: Proposal: Enhance requirements for General resolutions

[Gunnar Wolf]

Stephen Gran dijo [Mon, Mar 23, 2009 at 02:28:23PM +]:
> > Could you propose an amendement that explicitely says that the current
> > rules don't need to be changed (different from FD), and another one that
> > proposes a compromise by requiring 8 or 10 seconders?
> 
> You're aware that you can propose amendments as well?  It seems rather
> clunky to ask someone to write an amendment they don't agree with and
> hope that the wording is what you want.

To be fair, even more when I'm sitting at home after a full day of
work, I would really prefer putting my ideas in front of the others
and see if they make sense before formally proposing them. Besides,
quite often my English is quite below par to what I read on lists such
as this one - I am not saying that those are Lucas' motivations, but
they are nevertheless real :)

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [dissenting]: Proposal: Enhance requirements for General resolutions

[Gunnar Wolf]

Romain Beauxis dijo [Tue, Mar 24, 2009 at 01:12:34AM +0100]:
> Le Sunday 22 March 2009 23:53:02 Bill Allombert, vous avez écrit :
> > Furthermore I am a Debian since 2001 and I see no evidence than the GR
> > process was abused during that time. On the contrary, some GR were delayed
> > to the point where it was inconvenient for the release process.
> 
> I agree. I fail to see where the GR process was abused. Since that seems the 
> main argument in favour of this change, I fail to see the motivation for it.

This proposal does not come from an abuse to the GR process, but to
generalized frustration about the way 2008_002 and specially 2008_003
were handled.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [dissenting]: Proposal: Enhance requirements for General resolutions

[Russ Allbery]

Gunnar Wolf  writes:

> And FWIW, just not to forget the point: Several months ago, when this
> thread was last mentioned, I expressed my opinion on that _seconding_ a
> ballot should not be taken as _supporting_ the ballot - It might just be
> recognized as an important viewpoint to take into consideration, even
> for a particular DD who is against it.

If everyone seconds proposals that they'd vote above further discussion,
we *should* end up with a full slate of options which could pass.  It
shouldn't be necessary to second proposals that one would vote below
further discussion to get there.  (Although this does make some
assumptions that the population of seconders and the population of voters
is roughly equivalent.)

But yes, one does need to second anything one would vote above further
discussion, not just one's favorite choice, or it's possible to end up
without the best compromise position on the ballot.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org