Re: Draft resolution formalising Debian's Associated Project status

2007-02-28.iwj.1

Formally recording Debian's status as an Associated Project

WHEREAS

1. Debian is asubstantial and significant Free Software project;

2. SPI and Debian regard Debian as an SPI Associated Project; however

3. The detailed terms of the Association have not been formally
stated by the SPI Board in the manner now customary.

THE SPI BOARD DECLARES THAT

4. Debian is already an SPI Associated Project,
according to the SPI Framework for Associated Projects, SPI
Resolution 1998-11-16.iwj.1-amended-2004-08-10.iwj.1, a copy of
which can be found at
http://www.spi-inc.org/corporate/resolutions/2004-08-10-iwj.1.

5. The Debian Constitution (http://www.debian.org/devel/constitution),
and the persons holding the roles it defines and acting according
to that Constitution, are recognised by SPI as ultimately
authoritative regarding decisions of the Debian Project.

6. The SPI Board does not intend to monitor the Debian mailing lists.
The Board will recognise decisions, statements and delegations made
by the Debian Project Leader, currently Anthony Towns, as made on
behalf of Debian.

7. The Board specifically asks that the Debian Project Secretary
inform the SPI Board of any Debian General Resolutions which might
be relevant to SPI, including any proposals to put spending
decisions on hold.

8. The Board relies on Debian Developers and others to ensure that the
Board is made aware of any dispute or change regarding decisions or
authority of the Debian Project Leader (or indeed the Debian
Project Secretary).

9. The Debian Constitution in 5.1(10) gives the Project Leader the
primary responsibility to decide on the proper uses of assets held
in trust by SPI for Debian purposes.

Notwithstanding this, for the avoidance of any doubt, the SPI Board
and Treasurer cannot and will not delegate their judgement as to
whether a proposed use of assets meets SPI's charitable purposes.
As recognised by the Debian Constitution in 9.2(1), SPI must make
that decision, itself ensuring SPI's funds are used lawfully.

Ian.

On Wed, Feb 28, 2007 at 06:14:53PM +0000, Ian Jackson wrote:
> 1. Debian is asubstantial and significant Free Software project;

I'm sure everyone and their dog has already pointed out the typo over there...

> 6. The SPI Board does not intend to monitor the Debian mailing lists.
> The Board will recognise decisions, statements and delegations made
> by the Debian Project Leader, currently Anthony Towns, as made on
> behalf of Debian.
>
> 7. The Board specifically asks that the Debian Project Secretary
> inform the SPI Board of any Debian General Resolutions which might
> be relevant to SPI, including any proposals to put spending
> decisions on hold.

It seems inconsistent to mention the leader by name but not the secretary. :)
I'd omit both names.

--
2. That which causes joy or happiness.

On Wed, Feb 28, 2007 at 06:14:53PM +0000, Ian Jackson wrote:
> THE SPI BOARD DECLARES THAT
> 4. Debian is already an SPI Associated Project,
> according to the SPI Framework for Associated Projects, SPI
> Resolution 1998-11-16.iwj.1-amended-2004-08-10.iwj.1, a copy of
> which can be found at
> http://www.spi-inc.org/corporate/resolutions/2004-08-10-iwj.1.

I'd personally replace the rest with something like:

5. Debian may name an advisor to the board, who will have access to
the board private discussion, but (unless that person is already a
member of the board) shall not have any vote on the board.

6. Debian will appoint a project representative to SPI, who shall
communicate decisions made by the project to the board, and serve
as a single point of contact for the board to communicate with
the project.

7. The SPI board recognises that both those roles have been traditionally
filled by the Debian Project Leader, and are currently held by Anthony
Towns.

8. The SPI board recognises the Debian Constitution as the ultimate
authority by which the roles will be appointed, and by which
decisions are made by the Debian project.

> Notwithstanding this, for the avoidance of any doubt, the SPI Board
> and Treasurer cannot and will not delegate their judgement as to
> whether a proposed use of assets meets SPI's charitable purposes.
> As recognised by the Debian Constitution in 9.2(1), SPI must make
> that decision, itself ensuring SPI's funds are used lawfully.

Cheers,
aj

Anthony,

> 8. The SPI board recognises the Debian Constitution as the ultimate
> authority by which the roles will be appointed, and by which
> decisions are made by the Debian project.

We really need something to the effect that the SPI board is not
expected to read or act on anything which takes place on a debian-only
mailing list or forum unless a formal delegation brings it to the
Board's attention.

In the last year, we've repeatedly had SPI+Debian members speak up under
the misapprehension that the SPI board would act on something on
debian-vote on the board's own initiative.

--Josh Berkus

Anthony Towns writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> I'd personally replace the rest with something like:
>
> 5. Debian may name an advisor to the board, who will have access to
> the board private discussion, but (unless that person is already a
> member of the board) shall not have any vote on the board.

The advisor is covered by 2004-08-10.iwj.dbg.3 `Board Advisors'.

> 6. Debian will appoint a project representative to SPI, who shall
> communicate decisions made by the project to the board, and serve
> as a single point of contact for the board to communicate with
> the project.

I'm afraid that this fails to clarify precisely the situation that was
being disputed. What if the representative fails to honour some
Debian GR ? Now obviously we expect them not to but the resolution
should be written so that these cases are properly covered.

My version makes it clear that if the representative fails to honour a
GR (or some other aspect of Debian's governance) then (a) the SPI
Board won't necessarily find this out by itself so it will need to be
told and (b) when it is told the SPI Board will investigate with a
view to honouring both the letter and spirit of Debian's governance
arrangements as stated in the Constitution.

Ian.

On Thu, Mar 01, 2007 at 07:17:33PM +0000, Ian Jackson wrote:
> > 6. Debian will appoint a project representative to SPI, who shall
> > communicate decisions made by the project to the board, and serve
> > as a single point of contact for the board to communicate with
> > the project.
> I'm afraid that this fails to clarify precisely the situation that was
> being disputed. What if the representative fails to honour some
> Debian GR ?

Then that's something for Debian to resolve, up to and including
appointing a new project representative.

> Now obviously we expect them not to but the resolution
> should be written so that these cases are properly covered.

How is this any different to any other project having a representative
that doesn't pass on properly made decision?

Cheers,
aj

Anthony Towns writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> On Thu, Mar 01, 2007 at 07:17:33PM +0000, Ian Jackson wrote:
> > I'm afraid that this fails to clarify precisely the situation that was
> > being disputed. What if the representative fails to honour some
> > Debian GR ?
>
> Then that's something for Debian to resolve, up to and including
> appointing a new project representative.

Err, boggle. Firstly, dealing with that that way in Debian might well
be too slow. And secondly, the representative might `fail to
communicate' that they had been replaced.

There is absolutely no need to make the representative some kind of
all-governing oracle. To do so is definitely wrong and leaves us open
to abuse of authority.

> > Now obviously we expect them not to but the resolution
> > should be written so that these cases are properly covered.
>
> How is this any different to any other project having a representative
> that doesn't pass on properly made decision?

In the case of other projects where we've nominated an individual as
the `authoritative decisionmaker', that person was the leader of the
project.

NB that the authoritative decisionmaker doesn't have to be the same as
the representative; the authoritative decisionmaker is the person we
will believe if we can't tell the Judean People's Front apart from the
People's Front of Judea. The point is just that we need to write down
now (ie before any dispute arises) who is in charge or what the rules
are.

Ian.

On Mon, Mar 05, 2007 at 12:59:38PM +0000, Ian Jackson wrote:
> Anthony Towns writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> > On Thu, Mar 01, 2007 at 07:17:33PM +0000, Ian Jackson wrote:
> > > I'm afraid that this fails to clarify precisely the situation that was
> > > being disputed. What if the representative fails to honour some
> > > Debian GR ?
> > Then that's something for Debian to resolve, up to and including
> > appointing a new project representative.
> Err, boggle. Firstly, dealing with that that way in Debian might well
> be too slow. And secondly, the representative might `fail to
> communicate' that they had been replaced.

In what was is this different for Debian than any other project that
might wish to associate with SPI?

> There is absolutely no need to make the representative some kind of
> all-governing oracle. To do so is definitely wrong and leaves us open
> to abuse of authority.

Project representatives advise SPI, they don't have the ability to force
SPI to act.

> In the case of other projects where we've nominated an individual as
> the `authoritative decisionmaker', that person was the leader of the
> project.

And, uh, the "authoritative decisionmaker" for Debian is the duly elected
leader of the Debian project.

Cheers,
aj

On Mon, Mar 05, 2007 at 12:59:38PM +0000, Ian Jackson wrote:
> > Then that's something for Debian to resolve, up to and including
> > appointing a new project representative.
>
> Err, boggle. Firstly, dealing with that that way in Debian might well
> be too slow. And secondly, the representative might `fail to
> communicate' that they had been replaced.
>
> There is absolutely no need to make the representative some kind of
> all-governing oracle. To do so is definitely wrong and leaves us open
> to abuse of authority.

The general way you deal with this is you have a separation of
responsibilities. So you have one person from the team which is
designated as the official represenative, and another person who can
formally and legally notify SPI that the representative has been
replaced. So for example in Debian, this might be the DPL for one,
and the Project Secretary for the other.

Banks do something similar when you change who is allowed to sign
checks for a particular bank account. It is simply isn't appropriate
to ask Banks to monitor the internal workings of a particular
organization so they can be assured that the designated signatory on
the account is acting within his policies, bylaws, and constitution of
their particular organization.

The bottom line is that we need to optimize for the common case, where
you assume that the project representative is acting in good faith.
If we have a project which is so dysfunctional such that this is not
the common case, both the project and SPI has a much bigger set of
problems on its hands...

- Ted

AJ, Ian,

> > In the case of other projects where we've nominated an individual as
> > the `authoritative decisionmaker', that person was the leader of the
> > project.
>
> And, uh, the "authoritative decisionmaker" for Debian is the duly elected
> leader of the Debian project.

More to the point, even other projects with larger organizational structures
(e.g. PostgreSQL) have no expectations that SPI would monitor our internal
workings. If Josh Drake or Robert Treat got replaced in some disputed
election, we would expect SPI to simply freeze our funds until we worked it
out internally according to the charter we submitted on acceptance.

The issue we're having with Debian is the requests by a couple of prominent
(or at least vocal) Debian community members that we monitor, and react to,
actions on debian-vote, as well as dealing with claims by Debian community
members that the DPL was not authorized for some action and therefore the SPI
board shouldn't listen to him.

This sort of confusion between Debian politics and SPI governance is
understandable given that for a long time SPI pretty much was part of Debian
governance, but SPI is now broadening its reach and it's time to normalize
relations. Since there is this history of confusion, any resolution on the
topic should overdetermine the rules. It should include answers to these
questions, as clearly as possible:

(1) Does SPI listen only to the DPL, or to other Debian officers as well?
Under what circumstances?

(2) How does SPI determine that an officer has been replaced?

(3) If a recall vote is underway, should SPI pay any attention to it? If so,
in what way?

(4) If there is a dispute/disagreement on SPI lists between the DPL and other
Debian members/officers, how should the SPI board regard it?

Ian's resolution is one possible set of answers to these questions. AJ's
version is a different answer, which doesn't go far enough to answer all
questions and IMHO is not worth passing in its current form. I, personally,
don't care what the answers are as long as I can tell clearly and easily when
the DPL is entitled to cut checks for however much money he wants and when he
isn't.

--
Josh Berkus
PostgreSQL Project
Core Team Member
(any opinions expressed are my own)

Josh Berkus <josh(at)postgresql(dot)org> wrote:
> The issue we're having with Debian is the requests by a couple of prominent
> (or at least vocal) Debian community members that we monitor, and react to,
> actions on debian-vote, as well as dealing with claims by Debian community
> members that the DPL was not authorized for some action and therefore the SPI
> board shouldn't listen to him.

The issue we're having between SPI and the Debian project is the claim
by a couple of SPI board members that SPI only recognises DPL
decisions and not any of the other project decision-makers. As far as
I can tell, there isn't anything on record disagreeing with that
goalpost-move, although there's nothing much to support it either.
(Confusing statements by the current DPL about his authoritativity
don't help, although he's also promised to relate faithfully any
non-DPL decisions, so that isn't critical ATM.)

Who is demanding that SPI monitors and/or reacts to debian-vote
directly? Personally, I don't care whether SPI monitors debian
directly (if there's a problem, SPI will probably hear about it, as
many DDs are SPI members). I do care whether SPI refuses to recognise
valid decisions just because they aren't DPL-supported.

SPI pledges to obey all OFTC decisions. Please do the same for the
debian project.

Now, those questions:

> (1) Does SPI listen only to the DPL, or to other Debian officers as well?
> Under what circumstances?

To DPL about funding authorisations and new delegates, Auditor about
information and Secretary about any other project decisions.

> (2) How does SPI determine that an officer has been replaced?

AIUI, it depends on how they're replaced: the DPL (delegations) or
Secretary (GR outcomes) would notify SPI as appropriate. This already
happens for the DPL election, doesn't it?

> (3) If a recall vote is underway, should SPI pay any attention to it? If so,
> in what way?

No.

> (4) If there is a dispute/disagreement on SPI lists between the DPL and other
> Debian members/officers, how should the SPI board regard it?

With sorrow and caution? Not sure what this is asking.

Hope that helps,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

On Tue, Mar 06, 2007 at 12:01:00AM +0000, MJ Ray wrote:
> (Confusing statements by the current DPL about his authoritativity
> don't help, although he's also promised to relate faithfully any
> non-DPL decisions, so that isn't critical ATM.)

I consider them different hats:

- the DPL gets to make certain decisions on Debian's behalf as per
the constitution

- the Debian rep to SPI has to communicate all valid decisions from
Debian to the SPI board

- the Debian advisor to SPI should offer useful support and advice to
the board to help the organisation be as successful as possible

The first is a privilege, the second is a responsibility, the third is a
bit of both. (I don't think "authoritative decisionmaker" is an accurate
description of any of those roles)

Cheers,
aj

MJ,

> SPI pledges to obey all OFTC decisions.  Please do the same for the
> debian project.

Frankly, I wouldn't vote to approve the OFTC wording the way it stands if
they were applying to join today. It's too vague. However, since OFTC
actually needs very little, if anything, from SPI on a month-to-month
basis, I'm not proposing to change it on the principle of
it-aint-broke-don't-fix-it.

A request to "respect all Debian constitutional decisions" is pretty
useless without a charter specifying how those decisions are going to be
delivered to the board and how the board is supposed to know that they are
legitimate. This is what I believe that Ian was trying to address.

Actually, on the it-aint-broke-don't-fix-it front, what decision or
question has AJ, or his predecessor, *not* relayed reliably to the Board?
There's an implication on this thread that AJ is not trustworthy, and I
have yet to see evidence of it.

--
--Josh Berkus

Josh Berkus
PostgreSQL Project Core Team
www.postgresql.org

(all opinions expressed are my own; I do not speak
for the Project unless specifically noted.)

Josh Berkus <josh(at)postgresql(dot)org> wrote: [...]
> A request to "respect all Debian constitutional decisions" is pretty
> useless without a charter specifying how those decisions are going to be
> delivered to the board and how the board is supposed to know that they are
> legitimate. [...]

Fine. I think it's a good idea to commit to the goal *as well as*
stating what methods will be used to achieve it. If those methods
fail for some unforseen reason, then there'll still be the explicit
goal and we won't have the pain of getting a new resolution before
SPI can act.

> Actually, on the it-aint-broke-don't-fix-it front, what decision or
> question has AJ, or his predecessor, *not* relayed reliably to the Board?
> There's an implication on this thread that AJ is not trustworthy, and I
> have yet to see evidence of it.

No such implication from me on this thread. I welcome AJ's promise to
report accurately and trust him to keep it.

I feel the implication is that (all SPI board members over all time) +
(all DPLs over all time) are not trustworthy to preserve an unwritten
relationship. Given that we don't know who many of those people are,
that seems reasonable to me.

I feel it-aint-broke-don't-fix-it is often a bad argument. Why do
groups plan a complaints procedure before they get a complaint?

This isn't it-aint-broke-don't-fix-it anyway: I think there have been
at least three interpretations of the debian-SPI relationship posted
so far. What's real and what isn't?

Even if SPI decides to define the relationship in a way that
interferes in debian project decision-making, at least the project
will know where it stands before there's any dispute.

Hope that explains,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

Theodore Tso writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> The general way you deal with this is you have a separation of
> responsibilities. So you have one person from the team which is
> designated as the official represenative, and another person who can
> formally and legally notify SPI that the representative has been
> replaced. So for example in Debian, this might be the DPL for one,
> and the Project Secretary for the other.

This would be one way of doing it but it doesn't seem necessary to go
to that level of formality. SPI is a lot closer to Debian than a bank
is to its customers, and we have plenty of Debian Developers here to
make sure we find out if anything goes wrong.

> The bottom line is that we need to optimize for the common case, where
> you assume that the project representative is acting in good faith.
> If we have a project which is so dysfunctional such that this is not
> the common case, both the project and SPI has a much bigger set of
> problems on its hands...

Indeed so. This is why my proposal deals with the common case by
having the DPL tell us what the situation is, just as at present.

I didn't want to make this personal, but let me be blunt:

Anthony Towns writes:
> And, uh, the "authoritative decisionmaker" for Debian is the duly elected
> leader of the Debian project.

Anthony overreaches himself here. The authoritative decisionmaker for
Debian - the governing body - is the Developers via General
Resolution. Anthony as DPL is the executive - the decisionmaker of
first instance.

IMO this is not the first time he has overstepped the mark; on another
memorable recent occasion, after an enormously acrimonious debate, 15%
of Debian's governing body thought he had offended badly enough that
he should be sacked over it[1], as many as endorsed his actual
decision[2].

I therefore have no confidence that Anthony will know the bounds of
his own authority and I am not prepared to acquiesce to a statement
that relies on Anthony's judgement on these matters.

In particular, Anthony seems to be playing the role of Debian's SPI
advisor here - and what he is telling us inflates his own authority!

Ian.

[1] http://www.debian.org/vote/2006/vote_005
Of 330 DD's who cast ballots, 48 preferred Recall to the only
other option, Further Discussion.

[2] http://www.debian.org/vote/2006/vote_006
Of 333 DD's who cast ballots, 49 preferred `wish success to Dunc
Tank' to `do not endorse or support his other projects'.

> IMO this is not the first time he has overstepped the mark; on another
> memorable recent occasion, after an enormously acrimonious debate, 15%
> of Debian's governing body thought he had offended badly enough that
> he should be sacked over it[1], as many as endorsed his actual
> decision[2].
>
>
I have zero clue on the history here, but I must say.. if only 15% of
the people were upset, I am unsure
of what the problem is. 15% is nothing in the grand scheme of things.
> In particular, Anthony seems to be playing the role of Debian's SPI
> advisor here - and what he is telling us inflates his own authority!
>
>
Does the Debian constitution have a limits on what his authority
represents? Perhaps the problem is ambiguity on the
part of Debian? I don't want to start a war or anything and I do
appreciate your bluntness but my experience shows
that people in general, will overstep their bounds (assuming good
people) when they don't know what those
boundaries are.

Further my experience is that if 15% of a particular group is unhappy,
usually the person made a good choice. 40%? Not so much.

Joshua D. Drake

> Ian.
>
>
> [1] http://www.debian.org/vote/2006/vote_005
> Of 330 DD's who cast ballots, 48 preferred Recall to the only
> other option, Further Discussion.
>
> [2] http://www.debian.org/vote/2006/vote_006
> Of 333 DD's who cast ballots, 49 preferred `wish success to Dunc
> Tank' to `do not endorse or support his other projects'.
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general
>
>

Joshua D. Drake writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> Does the Debian constitution have a limits on what his authority
> represents?

Yes. For example:
- The DPL is not empowered to make technical decisions
- The DPL is not empowered to unilaterally expel Developers
- Any decision by the DPL can be overruled by a vote

This list is not exhaustive. The DPL has only the powers explictly
enumerated. You can read the constitution here:
http://www.debian.org/devel/constitution

> Further my experience is that if 15% of a particular group is unhappy,
> usually the person made a good choice. 40%? Not so much.

If I were the DPL I would consider my position very carefully if a
recall petition even got enough signatures to go to a ballot.

To put this in terms you may be familiar with: Anthony was impeached
and 15% of the decisionmaking body (those Developers who voted) were
in favour of forcing him out and holding an emergency election.

No other DPL has done anything controversial enough to put to a vote
to overrule the decision, let alone been subject to a vote whether to
recall them.

Ian.

On Tue, Mar 06, 2007 at 12:16:34PM +0000, Ian Jackson wrote:
> I didn't want to make this personal, but [...]

I think the phrase you're looking for is "so I won't".

> Anthony Towns writes:
> > And, uh, the "authoritative decisionmaker" for Debian is the duly elected
> > leader of the Debian project.
> Anthony overreaches himself here.

"Authoritative decisionmaker" is an SPI-specific term, that IMO, doesn't
reflect the role at all well, whether in relation to Debian, or other
SPI related projects. That's why I referred to it in scare quotes above,
and don't use it regarding the role by preference.

> IMO this is not the first time he has overstepped the mark; on another
> memorable recent occasion, after an enormously acrimonious debate, 15%
> of Debian's governing body thought he had offended badly enough that
> he should be sacked over it[1], as many as endorsed his actual
> decision[2].

> [1] http://www.debian.org/vote/2006/vote_005
> Of 330 DD's who cast ballots, 48 preferred Recall to the only
> other option, Further Discussion.
>
> [2] http://www.debian.org/vote/2006/vote_006
> Of 333 DD's who cast ballots, 49 preferred `wish success to Dunc
> Tank' to `do not endorse or support his other projects'.

Those are different sets of numbers. In the first vote, 277 people
voted FD, while 48 people voted for the recall, a difference of 229
votes. In the second vote, 177 people preferred "wish success", to "do
not endorse/support", while 128 preferred the opposite, a difference of
49 votes.

Cheers,
aj

On Tue, 6 Mar 2007, Ian Jackson wrote:
> > Further my experience is that if 15% of a particular group is unhappy,
> > usually the person made a good choice. 40%? Not so much.
>
> If I were the DPL I would consider my position very carefully if a
> recall petition even got enough signatures to go to a ballot.
>
> To put this in terms you may be familiar with: Anthony was impeached
> and 15% of the decisionmaking body (those Developers who voted) were
> in favour of forcing him out and holding an emergency election.

>From the results, it looks like AJ has an 83% approval rating, to continue
to use terms you may be familiar with. Most leaders would be envious of
such a rating.

> No other DPL has done anything controversial enough to put to a vote
> to overrule the decision, let alone been subject to a vote whether to
> recall them.

I am glad to hear the current DPL is willing to take risks. What a
horrible thing for a leader to do!

This thread is not supposed to be about putting the DPL on trial: that's
none of SPI's business. There will be an election soon in any case. Our
mission here is only to formalise the existing relationship between SPI
and Debian in a simple resolution acknowledging that the DPL or his
delegate is the contact point for the conveyance of decisions by Debian
and thus, from SPI's point of view, the decisionmaker even if he is only
passing on decisions made by GR. As has been stated, if the DPL is not
doing a good job of this, it is the responsibility of Debian to replace
that DPL, and the new DPL's responsibility to advise the board of the
removal of his predecessor, with appropriate citation as needed.

Thus the extent of the constitution's mention in the resolution should
only be to acknowledge that the DPL's powers are detailed in the
constitution of the project, leaving any matter of changed constitution in
the future up entirely to interpretation as it would be for any project.
In practical terms, this does not limit who can warn us that the leader's
powers have changed or have been overstepped while allowing us to have a
constructive relationship with the project through the DPL.

- -
David "cdlu" Graham - cdlu(at)railfan(dot)ca
Guelph, Ontario - http://www.cdlu.net/

On Tue, 2007-03-06 at 04:59 -0800, Joshua D. Drake wrote:
> > IMO this is not the first time he has overstepped the mark
> >
> I have zero clue on the history here, but I must say.. if only 15% of
> the people were upset, I am unsure of what the problem is. 15% is
> nothing in the grand scheme of things.
> > In particular, Anthony seems to be playing the role of Debian's SPI
> > advisor here - and what he is telling us inflates his own authority!
> >
> Does the Debian constitution have a limits on what his authority
> represents? Perhaps the problem is ambiguity on the part of Debian?

http://www.debian.org/devel/constitution

For the benefit of those not familiar with the depths of Debian history,
let me provide a little context. Ian played a significant role in the
drafting of the Debian constitution. The precipitous departure of Bruce
Perens from the project during the first leader election season, when he
and Ian were the two candidates, left Ian as the third and last DPL to
not be elected by the developers. Every DPL since has been elected
using the processes defined in the constitution.

Section 4.1 makes it clear that the developers by way of a general
resolution can overrule anything the DPL does. However, 5.1.10 and
5.1.11 make it equally clear that the DPL or an explicit DPL delegate is
who SPI should expect to interact with on a routine basis for decisions
regarding property held in trust for Debian. To the best of my
knowledge, the developers by way of a GR have never used the power in
4.1 to overrule a DPL decision... so that's an "escape valve" and not a
routine part of the Debian experience.

Decisions of the developers by way of a GR will always require time to
make. Sections 4.2.3-4 make it clear that "weeks" are involved.
Section 5.1.3 therefore explicitly notes that the DPL is empowered to
make any decision that "requires urgent action". By implication, the
developers by way of a GR should not expect to make many decisions
directly, and should instead focus on electing a DPL who adequately
represents their majority intent on routine matters.

> Further my experience is that if 15% of a particular group is unhappy,
> usually the person made a good choice. 40%? Not so much.

That's a good point.

My impression is that some of the most vigorous debates in the Debian
project in the last year have come when Anthony proposed doing something
"new", and following the spirit of 5.3, tried to build consensus for his
ideas among the developers before taking action. I've had some
interesting conversations with developers on three continents in recent
weeks about the power of a vocal minority to influence, distract, and
even disrupt a community operating largely by consensus. My personal
take is that as long as the DPL is actively trying to build consensus,
and acting in accord with the majority of developers, *the system is
working*.

Bdale

On Tue, Mar 06, 2007 at 07:53:12AM -0700, Bdale Garbee wrote:
> I've had some
> interesting conversations with developers on three continents in recent
> weeks about the power of a vocal minority to influence, distract, and
> even disrupt a community operating largely by consensus. My personal
> take is that as long as the DPL is actively trying to build consensus,
> and acting in accord with the majority of developers, *the system is
> working*.

I'd have to disagree, insomuch that when the vocal community makes it
extremely difficult for a DPL to do something new, and given the
proven difficulty to determine consensus *until* a recall election is
forced where the vocal minority was definitively shown to be a very
small minority indeed, that there is something badly broken in
Debian's governance model.

But Debian's dysfunctions aren't SPI's problem --- except that I would
strongly urge the SPI board to work extremely hard to get drawn into
Debian politics. This is something the SPI board should stay very,
very far away from, and the best way do that is to have a single
designated project representative. SPI should not stick its nose or
try to interpret the politics of any of its projects; Debian is just
one very good example why it shouldn't have anbything to do with a
project's internal politics.

- Ted

Ian,

> IMO this is not the first time he has overstepped the mark; on another
> memorable recent occasion, after an enormously acrimonious debate, 15%
> of Debian's governing body thought he had offended badly enough that
> he should be sacked over it[1], as many as endorsed his actual
> decision[2].

This may affect the DPL's re-election prospects but it's completely irrelevant
to the normalization of relations between Debian and SPI. In the case you
cite (Dunc-Tank) the DPL clearly communicated with us what things he was
asking for as DPL and what things he was arguing as Anthony Towns, SPI
member.

If AJ was "overstepping", he'd simply have asked me to cut Vorlon a check,
which I would have done, or represented Dunc-Tank as having the support of
Debian, which he did not, even though it cost him what he wanted. So you're
essentially saying that the DPL role is broken because the DPL created
controversy, which viewpoint I don't agree with.

> This would be one way of doing it but it doesn't seem necessary to go
> to that level of formality. SPI is a lot closer to Debian than a bank
> is to its customers, and we have plenty of Debian Developers here to
> make sure we find out if anything goes wrong.

I'm going to vote against any version of the resolution which does not spell
out Debian delegates' powers and responsibilities. While we haven't (to
date) had a problem with the DPL misrepresenting Debian constitutional
decisions, the same cannot be said of all DDs on spi-private. As the
Treasurer who is not a DD, I can't be satisfied by anything which says the
SPI board should "just know", or that they should take the word of just any
Debian-SPI member for it.

Any resolution I support will:
a) explicitly spell out the authority of the DPL
b) indicate who (by office, presumably) can bring us a Debian constitutional
decision in the event that it is not communicated by the DPL (such as after a
ratified recall vote)
c) indicate which other offices, if any, can ask for which other things from
the Board without explicit DPL delegation
d) indicate where we can verify the credentials of these officers.

All of this can be as simple as:
"The Debian Project Leader will be responsible for all communication between
Debian and SPI, and has full authority over all Debian assets held by SPI.
In the event that the DPL office is vacant, the Debian Secretary will
communicate decisions according to the Debian constitution to the SPI Board.
These decisions may be verified at www.debian.org/decisions."

--
Josh Berkus
Treasurer
Software in the Public Interest, Inc.
www.spi-inc.org

Josh Berkus writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> Any resolution I support will:
> a) explicitly spell out the authority of the DPL

You would like the Debian constitution incorporated bodily into the
resolution ? Because that's the accurate description of the DPL's
authority. It seems to me that it is better to refer to the
constitution by reference and for the SPI Board to read it if there is
a case of any doubt.

Would it help if we included a URL for the constitution, along the
lines of `at the time of writing, the Debian Constitution can be found
at http://www.debian.org/devel/constitution' ?

> b) indicate who (by office, presumably) can bring us a Debian
> constitutional decision in the event that it is not communicated by
> the DPL (such as after a ratified recall vote)

The Secretary, since the constitution makes them responsible for
holding votes (and reporting the results). My resolution makes this
clear, asking the Secretary to inform the SPI Board explicitly when
it's relevant.

> c) indicate which other offices, if any, can ask for which other
> things from the Board without explicit DPL delegation

Again, this is spelled out in the constitution although in practice
it's not likely to come up.

For example, if there were a dispute about whether to serve debian.org
with bind 9 (on box A) or some hypothetical DPL's home-grown bugware
(on box B), this would be a technical decision to be decided by the
Debian Technical Committee (subject again to any General Resolution to
overrule). If the DPL then went even madder and was refusing to pass
on the TC's decision then the TC chair would presumably email the SPI
Board asking them to give effect to the decision by changing the DNS
delegation, giving references to back up their authority and
presumably with the support of the Debian Project Secretary.

But this is all starting to sound rather too much like a game of
Nomic.

> d) indicate where we can verify the credentials of these officers.

This might be a good idea but it's difficult to write down - just as
the leadership succession in a smaller, less formalised, associated
project might not be so readily discoverable.

The best I think we can do is to name the current DPL, Secretary and
perhaps TC. I see that I have failed to put Manoj's name in my draft
which is a mistake.

> All of this can be as simple as: "The Debian Project Leader will be
> responsible for all communication between Debian and SPI, and has
> full authority over all Debian assets held by SPI. In the event
> that the DPL office is vacant, the Debian Secretary will communicate
> decisions according to the Debian constitution to the SPI Board.
> These decisions may be verified at www.debian.org/decisions."

But the DPL does _not_ have full authority over all Debian assets held
by SPI. The DPL's authority is limited by the Debian Constitution.

Ian.

I'm astonished at the pushback I'm having on the question of the
extent of the DPL's authority, and what SPI's position should be.

The situation is clear and there is absolutely no choice for SPI in
this matter. SPI _must_ honour the Debian Constitution, even in
case(s) where individual(s) (even the DPL) have a different view.

According to the Associated Project Framework[1], which is the basis
for the relationship between SPI and Debian:

If a Project has rules and procedures about its relationship with
SPI then SPI will honour them (for example by implementing decisons
about property held for that Project if and only if they are made
according to those rules and procedures) provided that they are
consistent with its agreement with SPI and with SPI's goals,
policies and legal obligations.

If a Project's internal organization or procedures are unclear or
disputed, SPI will deal with the situation as fairly as possible; if
possible SPI will act according to the decisions or rough consensus
of the Project's participants or in case of doubt that of the whole
Community.

The rules and procedures in question, in Debian's case, are precisely
the Debian constitution.

Note that in cases of doubt SPI is obliged to look at, and give effect
to, the project's governance structures. This is an essential
function for SPI. Since we have actual control over the purse-strings
it falls to us to give effect to the project's decisionmaking. We
can't evade that responsibility by nominating a particular individual
and always deferring to them.

Finally, this document is not just a feel-good policy statement and
doing as it says is not optional.

The Framework is the basis of the agreements between SPI and our
associated projects and has been the basis of our relationship with
Debian for nearly a decade. It is morally binding on SPI.

Additionally, it is legally binding on SPI as regards property held by
SPI for purposes related to Debian: that document is the basis of the
explicit charitable trust which governs how SPI may make use of those
assets.

So, SPI's deferral to the Debian Constitution is not optional, any
more than SPI's deferral to New York charity law is optional.
(Obviously the latter takes precedence, as described in the
Framework.)

Ian.

[1] http://www.spi-inc.org/corporate/resolutions/2004-08-10-iwj.1

On Tue, 2007-03-06 at 10:54 -0500, Theodore Tso wrote:

> I'd have to disagree, insomuch that when the vocal community makes it
> extremely difficult for a DPL to do something new, and given the
> proven difficulty to determine consensus *until* a recall election is
> forced where the vocal minority was definitively shown to be a very
> small minority indeed, that there is something badly broken in
> Debian's governance model.

I think we may be in violent agreement again, Ted... ;-)

I'm glad that the constitutional process did the right thing when
invoked, while you're lamenting a state of affairs inside the Debian
project where such a constitutional process was invoked at all.

> SPI should not stick its nose or
> try to interpret the politics of any of its projects; Debian is just
> one very good example why it shouldn't have anbything to do with a
> project's internal politics.

I actually think this is a point that (nearly?) everyone involved in
this discussion agrees with. If SPI is to avoid "sticking its nose"
into Debian project internals, then the resolution under discussion is
an important tool in that it is effectively an interface specification
between SPI and Debian. I think we've gotten pretty good at writing
these for recently associated projects, and am pleased that we're
getting around to putting one in place for the Debian interface.

Bdale

Ian, Bdale,

> Would it help if we included a URL for the constitution, along the
> lines of `at the time of writing, the Debian Constitution can be found
> at http://www.debian.org/devel/constitution'

Yes, *and* specific clause references. The Debian Constitution is 14 pages
long and changes every 2 years; you simply cannot expect a non-Debian SPI
Board member to read and interpret all of it as to whether it might apply to
Debian's relationship to SPI or the particular thing which SPI is being asked
to do. For reference, the PostgreSQL charter on interacting with SPI is
*one* page, and the ones for other organizations are one *paragraph.*

From what I can tell, the only relevant paragraphs are: 5.1.3, 5.1.10 and
5.1.11. Further, I (as Treasurer) would pretty much ignore the part of
5.1.10 which says: "Major expenditures should be proposed and debated on the
mailing list before funds are disbursed.", simply because I have no way to
verify that they have or haven't been.

> The Secretary, since the constitution makes them responsible for
> holding votes (and reporting the results). My resolution makes this
> clear, asking the Secretary to inform the SPI Board explicitly when
> it's relevant.

Yes, I liked that about your proposal.

> > c) indicate which other offices, if any, can ask for which other
> > things from the Board without explicit DPL delegation
>
> Again, this is spelled out in the constitution although in practice
> it's not likely to come up.

I wasn't thinking about *disputes* with the DPL. I was thinking, for example,
if the Debian Auditor e-mails me out of the blue asking for detailed
financial information, do I give it to her or do I ask the DPL first?

> This might be a good idea but it's difficult to write down - just as
> the leadership succession in a smaller, less formalised, associated
> project might not be so readily discoverable.

So the names of the officers aren't posted anywhere on the Debian web site?
There are no public archives of debian-vote?

> If SPI is to avoid "sticking its nose"
> into Debian project internals, then the resolution under discussion is
> an important tool in that it is effectively an interface specification
> between SPI and Debian.

*exactly*

I feel like I keep saying, "I want a simple API definition" and Ian & MJ keep
saying "read the whole codebase".

--
Josh Berkus
PostgreSQL Project
Core Team Member
(any opinions expressed are my own)

On Tue, Mar 06, 2007 at 11:19:31AM -0700, Bdale Garbee wrote:
> I actually think this is a point that (nearly?) everyone involved in
> this discussion agrees with. If SPI is to avoid "sticking its nose"
> into Debian project internals, then the resolution under discussion is
> an important tool in that it is effectively an interface specification
> between SPI and Debian. I think we've gotten pretty good at writing
> these for recently associated projects, and am pleased that we're
> getting around to putting one in place for the Debian interface.

Agreed, we are agreeing violently. The only thing that should be
needed for the ABI is the DPL and the Debian Project Secretary.
Nothing else should be necessary.

For *sure* we should not be requiring the SPI board to read the 14
pages of the constitution plus any potential Debian GR's, plus all of
the flamewars on the debian mailing lists about how to interpret the
whole mess.

- Ted

On Tue, 06 Mar 2007, Josh Berkus wrote:
> Yes, *and* specific clause references. The Debian Constitution is 14
> pages long and changes every 2 years;

It changes when it changes; time has no relevance to when amendments
are proposed and incorporated.

> you simply cannot expect a non-Debian SPI Board member to read and
> interpret all of it as to whether it might apply to Debian's
> relationship to SPI or the particular thing which SPI is being asked
> to do.

There's no problem with requiring that Debian Developers who are also
members of SPI bring up any such irregularities. The project liason
should be capable of providing the details of most decisions, but in
the case of a conflict, the constitution must control.

> For reference, the PostgreSQL charter on interacting with SPI is
> *one* page, and the ones for other organizations are one
> *paragraph.*

Brevity, while a laudable persuit, often leads to unforgivable holes.
Far better for a document to be 10 pages long and properly deal with
the cases at hand than 1 sentence long and fail utterly.

> So the names of the officers aren't posted anywhere on the Debian
> web site? There are no public archives of debian-vote?

They're posted and made available, but SPI shouldn't need to go find
them.

> I feel like I keep saying, "I want a simple API definition" and Ian
> & MJ keep saying "read the whole codebase".

There's no problem with providing a simplified API definition, but in
cases of conflict, the actual codebase (as it does in the case of API
definitions) controlls.

Don Armstrong

--
There is no such thing as "social gambling." Either you are there to
cut the other bloke's heart out and eat it--or you're a sucker. If you
don't like this choice--don't gamble.
-- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com http://rzlab.ucr.edu

>
> If I were the DPL I would consider my position very carefully if a
> recall petition even got enough signatures to go to a ballot.
>

Yeah, I could see that.

> To put this in terms you may be familiar with: Anthony was impeached
> and 15% of the decisionmaking body (those Developers who voted) were
> in favour of forcing him out and holding an emergency election.
>
O.k. this is slightly different than what I was thinking happen. Thanks
for clearing it up.
> No other DPL has done anything controversial enough to put to a vote
> to overrule the decision, let alone been subject to a vote whether to
> recall them.
>
Nod.

Sincerely,

Joshua D. Drake

> Ian.
>
>

On 06-Mar-07, 15:37 (CST), "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
> >To put this in terms you may be familiar with: Anthony was impeached
> >and 15% of the decisionmaking body (those Developers who voted) were
> >in favour of forcing him out and holding an emergency election.
> >
> O.k. this is slightly different than what I was thinking happen. Thanks
> for clearing it up.

It's also slightly[1] different from what actually happened. In the US,
impeachment is an indictment, requiring allegation of "high treason,
bribery, or other high crimes and misdemeanors". It also requires a
*majority* vote of the members of the US House of Representatives.

In contrast, the instigation of the GR required the action of only
10 people, one of whom was Anthony himself. That's 1% of the Debian
developers. The actual vote drew 48 against the DPL, or about 5% of the
total, or 15% of the voters.

Politicians in the US *dream* of 85% approval ratings.

Steve

[1] Here, I'm using "slightly" to mean "almost completely".

--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net

On Tue, Mar 06, 2007 at 10:54:49AM -0500, Theodore Tso wrote:
> But Debian's dysfunctions aren't SPI's problem --- except that I would
> strongly urge the SPI board to work extremely hard to get drawn into
> Debian politics.

Could I just suggest adding a "not" to that sentence? :)

Cheers,
aj

On Mon, Mar 05, 2007 at 09:27:14AM -0500, Theodore Tso wrote:
> The general way you deal with this is you have a separation of
> responsibilities. So you have one person from the team which is
> designated as the official represenative, and another person who can
> formally and legally notify SPI that the representative has been
> replaced. So for example in Debian, this might be the DPL for one,
> and the Project Secretary for the other.

Er, isn't that the description of Ian's proposal in this matter? :)

--
2. That which causes joy or happiness.

On Wed, Feb 28, 2007 at 06:14:53PM +0000, Ian Jackson wrote:
> Formally recording Debian's status as an Associated Project

While we're at it, shouldn't there be a similar resolution for Fresco?

--
2. That which causes joy or happiness.

Theodore Tso <tytso(at)mit(dot)edu> wrote:
> [...] the best way do that is to have a single
> designated project representative. SPI should not stick its nose or
> try to interpret the politics of any of its projects; [...]

I think that's absurd: by designating a single project representative,
SPI would be sticking its nose into the debian project's politics and
essentially rewriting the project constitution in a small way.

If SPI really wants to do that, it can, but I don't think SPI should
break past promises so lightly. What is the compelling need to break
this promise?

Most of the time, SPI and the debian project will interact smoothly,
just as they have for years without any written SPI statement, until
some of this board. It doesn't seem very stressful for SPI to follow
a project's constitution (and so ask the debian project secretary, who
"adjudicates any disputes about interpretation of the constitution" at
present) the one time in a few hundred that it doesn't run smoothly.

Regards,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

Josh Berkus <josh(at)postgresql(dot)org> wrote:
> I feel like I keep saying, "I want a simple API definition" and Ian & MJ keep
> saying "read the whole codebase".

I meant to say "summarise the API if you want, but acknowledge that
the codebase decides the API" - IOW, project constitutions are
authoritative and SPI doesn't seek to change them.

Hey, do you think that there should be a stable ABI for Linux drivers?
;-)

Regards,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

On Thu, Mar 08, 2007 at 11:30:29AM +0000, MJ Ray wrote:
> Josh Berkus <josh(at)postgresql(dot)org> wrote:
> > I feel like I keep saying, "I want a simple API definition" and Ian & MJ keep
> > saying "read the whole codebase".
>
> I meant to say "summarise the API if you want, but acknowledge that
> the codebase decides the API" - IOW, project constitutions are
> authoritative and SPI doesn't seek to change them.

When you get a checking account for any non-profit organization, the
bank wants one or two people to be authorized signatories on the
account, and each year when there is an election the secretary or some
other officer sends a official letter to the bank (with a
countersignature from one of the people who are currently authorized
to sign on the account) saying who the new people with signature
authority should be.

This is a simple API, but it does not involve "rewriting the project
constitution". Claiming that the project constitution requires SPI or
a bank to be intimately involved with the project internal politics is
completely bogus and makes no sense.

- Ted

MJ,

> I meant to say "summarise the API if you want, but acknowledge that
> the codebase decides the API" - IOW, project constitutions are
> authoritative and SPI doesn't seek to change them.

Sure. But let's have the definition of the API. Which includes a
*limited* number of representatives (most likely, DPL and Secretary) and
not "read the consititution to figure out who you have to speak to"

The SPI Board should only have to look at the Debian constitution and
public voting records under *extreme* circumstances, such as forking of
the Debian project.

> Hey, do you think that there should be a stable ABI for Linux drivers?
> ;-)

Right, my point exactly.

--Josh

Theodore Ts'o <tytso(at)mit(dot)edu> wrote:
> When you get a checking account for any non-profit organization, the
> bank wants one or two people to be authorized signatories [...]

True but largely irrelevant, which is why I didn't comment on this
analogy last time it was posted. I apologise for the detail here, but
in short, I think it ignores who resolves what when a group opens a
bank account and that the named signatories are not necessarily the
account holder.

The detailed banking/signatory resolutions I've signed are made by the
group, not the bank. We already have a group "resolution" here: the
Debian project constitution. I know most banking resolutions use a
suggested wording from the bank and the bank sometimes insists on
particular features, but those are usually set by general policy, not
on a per-account basis. Per-account offers would leave a bank open to
all sorts of accusations of favouritism and inconsistency, as well as
being a non-scaling nightmare to manage. SPI has already approved a
general policy: the associated project framework. Included in that is
a promise not to interfere in project decision-making.

If the SPI "bank" now insists on features like no recognition of
non-"signatory" decision-making (if it exists - AFAIK it doesn't for
most SPI projects), SPI should change its policy and then ask each
affected group for new mandates or exits. I think it's improper to
unilaterally impose it, especially given that SPI was asked to comment
on updating that mandate only a few months ago and didn't! (At least,
I found no reply on debian-vote or spi-general.)

No bank that I've seen refuses to respect all properly-made decisions
of the account holder, even if there are named signatories. In fact,
I'm not sure it's valid to do so: if the group wants to close its
account but the signatories don't, the account holder (group) wins.
A DPL-only/constitution-free resolution would make the debian project
account into the DPL account, wouldn't it? Is SPI sure that it can
redesignate donations to the debian project as donations to the debian
project leader?

At least the debian project would know more clearly what "account" it
had, instead of the conflicting arguments from board members about
whether non-DPL decisions can use SPI-held property.

> This is a simple API, but it does not involve "rewriting the project
> constitution". Claiming that the project constitution requires SPI or
> a bank to be intimately involved with the project internal politics is
> completely bogus and makes no sense.

Which is why no-one seems to be doing that besides strawman-building,
presumably.

Just nominating one individual seems incomplete and would mean that 1/
SPI would have to re-resolve if the debian project took certain
decisions about its relationship with SPI; and/or 2/ SPI would not
recognise some debian project decisions without another SPI
resolution; and/or 3/ the funds would be DPL funds rather than debian
project funds (which will usually mean the same, but maybe not
always). Neither 1 or 2 scale, and I believe 3 would be interfering
in project internal decision-making and possibly other problems.

2007-02-28.iwj.1 included both individuals as recognition of the
current situation and ultimate authority of the project's
constitution, while emphasising that project members should alert SPI
to any relevant things not mentioned by the individual. I think that
was a sound approach and answered most tell-me-who-to-listen-to
requests. I'm disappointed the current DPL objected to it.

I'm not going to comment on the 85% approval rating guff here, except
to lament the continuing rise of confrontation politics over my
preferred cooperation and consensus: it'd be better to react to honest
"this is the line I'll not cross" statements by meeting on common
ground instead of opening battle-fronts at those lines.

Hope that explains,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

MJ,

> 2007-02-28.iwj.1 included both individuals as recognition of the
> current situation and ultimate authority of the project's
> constitution, while emphasising that project members should alert SPI
> to any relevant things not mentioned by the individual.

I'm fine with Ian's proposal except for clause (8), which I would prefer to
name Debian officers instead of "Debian Developers and others". I've
already seen DD's on *this* list misrepresent the situation re: DPL
authority (i.e. the recall vote) and am simply not prepared to make a
judgement call on whether to take your word or Anthony's. So I'd prefer
that clause 8 be stricken, since none of the other Debian officers are
enumerated in the Constitution.

--
--Josh

Josh Berkus
Treasurer
Software in the Public Interest, Inc.
treasurer(at)spi-inc(dot)org

On Thu, Mar 08, 2007 at 11:29:08AM -0800, Josh Berkus wrote:
> > 2007-02-28.iwj.1 included both individuals as recognition of the
> > current situation and ultimate authority of the project's
> > constitution, while emphasising that project members should alert SPI
> > to any relevant things not mentioned by the individual.
>
> I'm fine with Ian's proposal except for clause (8), which I would prefer to
> name Debian officers instead of "Debian Developers and others". I've
> already seen DD's on *this* list misrepresent the situation re: DPL
> authority (i.e. the recall vote) and am simply not prepared to make a
> judgement call on whether to take your word or Anthony's. So I'd prefer
> that clause 8 be stricken, since none of the other Debian officers are
> enumerated in the Constitution.

I don't see how clause 8 hurts - so what if there's disagreement? The eighth
clause simply says that the SPI board will listen to Debian developers *and
anyone else* saying something changed or is disputed about the DPL or the
secretary - it doesn't say that the SPI board needs to act upon anything.

It seems to me as a fairly generic statement - anyone, and it will probably
be the developers of Debian, can tell the SPI board that something changed
or something went wrong. After that, the board is not obliged to make any
judgements. It can, however, do something moderately sensible, like for
example ask the DPL and/or secretary if what those other people are saying
is true or not.

Leaving out the clause would merely leave the procedure on what to do
if e.g. a rogue secretary and a rogue leader who were replaced at the
Debian Project but did not tell the board that they were replaced -
somewhat undocumented.

--
2. That which causes joy or happiness.

On Thu, Mar 08, 2007 at 11:15:48PM +0100, Josip Rodin wrote:
> I don't see how clause 8 hurts - so what if there's disagreement? The eighth
> clause simply says that the SPI board will listen to Debian developers *and
> anyone else* saying something changed or is disputed about the DPL or the
> secretary - it doesn't say that the SPI board needs to act upon anything.

Well, to the extent that the SPI board can listen to anyone, it may be
harmless. But suppose someone cc's the spi-board to a mailing list
flame war from a debian-mailing list that goes on for 500, 600
messages? Would clause 8 mean that the SPI board is obligated to read
each and every one of the messages, and not be allowed to killfile the
thread?

The real concern here from the SPI point of view is legal liability.
If there is a rogue DPL and a rogue secretary, and the SPI acts on the
instructions given by its contacts as detailed in its policies and
procedures, then the DPL and the secretary may be personally legally
liable for going beyond the scope of their responsibilities, but the
SPI is in the clear.

If however the SPI is responsible for making a judgement call about
the murky nature of Debian politics, particularly since certain
aspects of Debian's policies and procedures are not necessarily
clearly defined (or at least subject to dispute leading to mailing
list flames that go on and on for hundreds of messages) from a legal
point of view, then SPI could get dragged into what could be a nasty,
and potentially arbitrarily expensive legal adjucation procedure.

Hence, in order for SPI to protect itself, it is best from SPI's point
of view to have a very strictly defined interface with which it
interacts with its sub-projects, much like a bank has a strictly
defined interface with its customers --- and for the same reasons.
The legal exposure, not to mention the exposure to vast debian mailing
list flame wars to SPI board members who are not otherwise obligated
to be on various Debian mailing list, would be enormous.

Regards,

- Ted

On Sat, Mar 10, 2007 at 07:53:22AM -0500, Theodore Tso wrote:
> Well, to the extent that the SPI board can listen to anyone, it may be
> harmless. But suppose someone cc's the spi-board to a mailing list
> flame war from a debian-mailing list that goes on for 500, 600
> messages? Would clause 8 mean that the SPI board is obligated to read
> each and every one of the messages, and not be allowed to killfile the
> thread?

(I don't think this is particularly relevant, because it would mean that
someone would have to sue SPI for having been killfiled... imagine that :)

> If however the SPI is responsible for making a judgement call

Again this... Hmm. I've re-read the text now, and I see that the problematic
part is that it mentions both 'any dispute regarding decisions' and
'any change regarding authority', but combined into one sentence.

I figure that from a legal standpoint you want to remove the first part,
but keeping the second part is fine. I think that that would be a decent
compromise. The cases where there is a dispute regarding officer decisions
can be handled internally by Debianites, and they can modify the said
officers' authority, and then tell SPI that such a change had happened.

I figure that the first part was aiming for the SPI board to be able to stop
a rogue leader and secretary from spending all of Debian's money away before
the constitutional procedures to stop them had any chance to complete.
However, the text didn't really go far enough with that - what if the SPI
board is duly informed about something like that, but it still decides to go
through with transactions because it doesn't think they're a problem?

Anyway, do other associated projects implement any similar safeguards?

--
2. That which causes joy or happiness.

Josip,

> Anyway, do other associated projects implement any similar safeguards?

Speaking for PostgreSQL, no, not really. However, it takes us less than a
week to replace our Liason if it becomes necessary, and frankly our charter
was written with having a second PostgreSQL person on the board as assumed,
so that person acts as a brake on the Liason going 'round the bend.

Also, I think we have more faith in our ability to pick a liason who won't go
berserk. ;-)

--
Josh Berkus
PostgreSQL Project
Core Team Member
(any opinions expressed are my own)

Ted,

> If however the SPI is responsible for making a judgement call about
> the murky nature of Debian politics, particularly since certain
> aspects of Debian's policies and procedures are not necessarily
> clearly defined (or at least subject to dispute leading to mailing
> list flames that go on and on for hundreds of messages) from a legal
> point of view, then SPI could get dragged into what could be a nasty,
> and potentially arbitrarily expensive legal adjucation procedure.

I'm not so worried about legal culpability (how would Debian sue SPI when SPI
provides Debian's legal help?). However, I *am* worried about making the
wrong decision, and pissing off the "winners" in a long-running Debian
dispute, and thus causing Debian members to distrust SPI and call for
pulling out. This is *directly* based on my experience with the Dunc-Tank
proposal.

I really don't think that MJ and Ian realize how opaque and chaotic Debian
politics are to outsiders.

--
Josh Berkus
Treasurer
Software in the Public Interest, Inc.
www.spi-inc.org

On Sun, Mar 11, 2007 at 11:28:41AM -0700, Josh Berkus wrote:
> > If however the SPI is responsible for making a judgement call about
> > the murky nature of Debian politics, particularly since certain
> > aspects of Debian's policies and procedures are not necessarily
> > clearly defined (or at least subject to dispute leading to mailing
> > list flames that go on and on for hundreds of messages) from a legal
> > point of view, then SPI could get dragged into what could be a nasty,
> > and potentially arbitrarily expensive legal adjucation procedure.
>
> I'm not so worried about legal culpability (how would Debian sue SPI
> when SPI provides Debian's legal help?). However, I *am* worried
> about making the wrong decision, and pissing off the "winners" in a
> long-running Debian dispute, and thus causing Debian members to
> distrust SPI and call for pulling out. This is *directly* based on
> my experience with the Dunc-Tank proposal.

Hopefully it would never come to one side gathering up enough money to
sue the other side *and* SPI due to some internal Debian dispite; but
then again the whole brou-ha-ha over whether or not some Debian
Developers are allowed to be paind money (either by Debian or by a
group of DD's who are exercise their right of free association to
funnel money towards other DD's) have already caused people to do
things that I wouldn't have thought likely for reasonable people to
do, so it's something that I'd worry about, at least.

> I really don't think that MJ and Ian realize how opaque and chaotic
> Debian politics are to outsiders.

Outsiders, heck! What about to insiders? :-)

- Ted

Josh Berkus wrote:
> Josip,
>
>> Anyway, do other associated projects implement any similar safeguards?
>
> Speaking for PostgreSQL, no, not really. However, it takes us less than a
> week to replace our Liason if it becomes necessary, and frankly our charter
> was written with having a second PostgreSQL person on the board as assumed,
> so that person acts as a brake on the Liason going 'round the bend.

Actually 10 days ;) but yes PostgreSQL is set up to have some fairly
easy control in replacing their Liason.

>
> Also, I think we have more faith in our ability to pick a liason who won't go
> berserk. ;-)

Thanks ;0

Joshua D. Drake

>

Josh Berkus wrote:
> Ted,
>
>> If however the SPI is responsible for making a judgement call about
>> the murky nature of Debian politics, particularly since certain
>> aspects of Debian's policies and procedures are not necessarily
>> clearly defined (or at least subject to dispute leading to mailing
>> list flames that go on and on for hundreds of messages) from a legal
>> point of view, then SPI could get dragged into what could be a nasty,
>> and potentially arbitrarily expensive legal adjucation procedure.
>
> I'm not so worried about legal culpability (how would Debian sue SPI when SPI
> provides Debian's legal help?). However, I *am* worried about making the
> wrong decision, and pissing off the "winners" in a long-running Debian
> dispute, and thus causing Debian members to distrust SPI and call for
> pulling out. This is *directly* based on my experience with the Dunc-Tank
> proposal.
>
> I really don't think that MJ and Ian realize how opaque and chaotic Debian
> politics are to outsiders.

I would second that. When I researched the OpenSource.Org domain issue,
I was stunned at how convoluted and emotional everything was. Debian has
really appears to have grown (at least from an outsider view) into a
very political self spinning organization.

Joshua D. Drake

On Sun, Mar 11, 2007 at 11:20:52AM -0700, Josh Berkus wrote:
> > Anyway, do other associated projects implement any similar safeguards?
>
> Speaking for PostgreSQL, no, not really. However, it takes us less than a
> week to replace our Liason if it becomes necessary, and frankly our charter
> was written with having a second PostgreSQL person on the board as assumed,
> so that person acts as a brake on the Liason going 'round the bend.

It would take eleven Debian developers making a resolution within the
project in order to get an injuction on a decision by the leader.
(That's how I read Debian Constitution paragraphs 4.2.2.2 + 4.2.7.)

With this SPI resolution saying that those developers can then inform the
SPI board about that injunction, which the SPI board should interpret as
a change in authority of the project leader (ignoring the fact that it's
also a dispute - the injunction is a clear constitutional tool and not a
matter of judgement), we would actually be very swift.

> Also, I think we have more faith in our ability to pick a liason who won't
> go berserk. ;-)

I know you're joking, but jokes aside, I don't think it should be an issue
of faith.

--
2. That which causes joy or happiness.

> With this SPI resolution saying that those developers can then inform the
> SPI board about that injunction, which the SPI board should interpret as
> a change in authority of the project leader (ignoring the fact that it's
> also a dispute - the injunction is a clear constitutional tool and not a
> matter of judgement), we would actually be very swift.
>
>> Also, I think we have more faith in our ability to pick a liason who won't
>> go berserk. ;-)
>
> I know you're joking, but jokes aside, I don't think it should be an issue
> of faith.

Well Debian never spends any money anyway so... ;)

Joshua D. Drake

On Sun, Mar 11, 2007 at 02:20:41PM -0700, Joshua D. Drake wrote:
> >I really don't think that MJ and Ian realize how opaque and chaotic Debian
> >politics are to outsiders.
>
> I would second that. When I researched the OpenSource.Org domain issue,
> I was stunned at how convoluted and emotional everything was. Debian has
> really appears to have grown (at least from an outsider view) into a
> very political self spinning organization.

I'd like to respond to that, but I really don't understand what you mean by
'political self spinning organization'? A political organization that
spins on its own? WTF? :)

Regarding Debian vs. OSI in general, it's an inevitably strange relationship
because of the simple fact that a closed organization forked a foundation
document of an open project. Like in that other thread - we don't like to
leave things as a matter of faith, let alone to a closed group. Sure, it's
reasonably easy to believe that OSI will do no harm, but us technical types
aren't inclined to like such uncertainty.

Which is amusing - this apparently became "opaque and chaotic" as described
above, and that's the very thing that we would like to have avoided...

--
2. That which causes joy or happiness.

> With this SPI resolution saying that those developers can then inform the
> SPI board about that injunction, which the SPI board should interpret as
> a change in authority of the project leader (ignoring the fact that it's
> also a dispute - the injunction is a clear constitutional tool and not a
> matter of judgement), we would actually be very swift.
>
>> Also, I think we have more faith in our ability to pick a liason who won't
>> go berserk. ;-)
>
> I know you're joking, but jokes aside, I don't think it should be an issue
> of faith.

Everything is an issue of faith. PostgreSQL is able to operate easily
without draconian rules by using a level of trust for its participants.

In business, I am taking faith that someone will pay the invoice for the
work rendered. If they don't, I sue. That is no different with PostgreSQL.

If the PostgreSQL Liaison started acting in a way that was directly
counter to the implicit interests of the PostgreSQL community, he/she
could be removed by the PostgreSQL Fundraising Group.

Further if it was considered fraudulent activity the SPI could sue and
or file charges (depending on what happen) that individual.

Sincerely,

Joshua D. Drake

On Sun, Mar 11, 2007 at 04:27:38PM -0700, Joshua D. Drake wrote:
> > I don't think it should be an issue of faith.
>
> Everything is an issue of faith. PostgreSQL is able to operate easily
> without draconian rules by using a level of trust for its participants.
>
> In business, I am taking faith that someone will pay the invoice for the
> work rendered. If they don't, I sue. That is no different with PostgreSQL.
>
> If the PostgreSQL Liaison started acting in a way that was directly
> counter to the implicit interests of the PostgreSQL community, he/she
> could be removed by the PostgreSQL Fundraising Group.
>
> Further if it was considered fraudulent activity the SPI could sue and
> or file charges (depending on what happen) that individual.

Yes, exactly, and the basis of any of these complaints would be the
straightforward procedures that would have been contravened. That's what
I meant by not having issues of faith - everything that can be spelled out
should be spelled out, so that the amount of arguable stuff is minimized.

--
2. That which causes joy or happiness.

Josip Rodin wrote:
> On Sun, Mar 11, 2007 at 02:20:41PM -0700, Joshua D. Drake wrote:
>>> I really don't think that MJ and Ian realize how opaque and chaotic Debian
>>> politics are to outsiders.
>> I would second that. When I researched the OpenSource.Org domain issue,
>> I was stunned at how convoluted and emotional everything was. Debian has
>> really appears to have grown (at least from an outsider view) into a
>> very political self spinning organization.
>
> I'd like to respond to that, but I really don't understand what you mean by
> 'political self spinning organization'? A political organization that
> spins on its own? WTF? :)

Perpetual motion, never stops, never moves forward.

>
> Regarding Debian vs. OSI in general, it's an inevitably strange relationship
> because of the simple fact that a closed organization forked a foundation
> document of an open project. Like in that other thread - we don't like to
> leave things as a matter of faith, let alone to a closed group. Sure, it's
> reasonably easy to believe that OSI will do no harm, but us technical types
> aren't inclined to like such uncertainty.
>
> Which is amusing - this apparently became "opaque and chaotic" as described
> above, and that's the very thing that we would like to have avoided...

Well I certainly don't want to start up the discussion again. I was just
making a point about a particular incident that I saw.

The most gentle way that I could put it, is:

As an outsider, it appears that Debian is more interested in policy than
actually achieving goals. This in turn reminds many of how governments
work. Very slow, very unproductive, but they eventually get things done.

Whether this is true or not, I really don't know. I don't follow Debian
except to how it relates with Ubuntu of which I am a big fan. I do not
have harbor any real thoughts on the matter beyond what I mention above
because I am not involved beyond with Debian beyond the relationship
with SPI.

Sincerely,

Joshua D. Drake

Josip,

> It would take eleven Debian developers making a resolution within the
> project in order to get an injuction on a decision by the leader.
> (That's how I read Debian Constitution paragraphs 4.2.2.2 + 4.2.7.)

Yes, but I can see other interpretations of that article. That's why I feel
that "reference the Debian constitution" and/or "any other person" isn't
specific enough; I'd want to have the above **spelled out** in the liason
document, not just in the Debian constitution. As well as what the board is
supposed to do about it.

--
Josh Berkus
PostgreSQL Project
Core Team Member
(any opinions expressed are my own)

On Sun, Mar 11, 2007 at 04:35:19PM -0700, Joshua D. Drake wrote:
> >>>I really don't think that MJ and Ian realize how opaque and chaotic
> >>>Debian politics are to outsiders.
> >>I would second that. When I researched the OpenSource.Org domain issue,
> >>I was stunned at how convoluted and emotional everything was. Debian has
> >>really appears to have grown (at least from an outsider view) into a
> >>very political self spinning organization.
> >
> >I'd like to respond to that, but I really don't understand what you mean by
> >'political self spinning organization'? A political organization that
> >spins on its own? WTF? :)
>
> Perpetual motion, never stops, never moves forward.

That happens when an issue remains unresolved. It can happen everywhere
where many non-trivial issues are dealt with, it's not specific to Debian...

> >Regarding Debian vs. OSI in general, it's an inevitably strange
> >relationship
> >because of the simple fact that a closed organization forked a foundation
> >document of an open project. Like in that other thread - we don't like to
> >leave things as a matter of faith, let alone to a closed group. Sure, it's
> >reasonably easy to believe that OSI will do no harm, but us technical types
> >aren't inclined to like such uncertainty.
> >
> >Which is amusing - this apparently became "opaque and chaotic" as described
> >above, and that's the very thing that we would like to have avoided...
>
> Well I certainly don't want to start up the discussion again. I was just
> making a point about a particular incident that I saw.
>
> The most gentle way that I could put it, is:
>
> As an outsider, it appears that Debian is more interested in policy than
> actually achieving goals.

In this particular matter, that's true in a way that there was never anybody
else equally interested in "open source dot org" (other than the OSI folks),
someone who would implement a non-closed organization to handle the same
thing. People generally wanted for it to get done "right", but nobody
stepped up and did it, so it didn't get done; instead, it got done by the
OSI folks, the way that is not "right".

So, people will always be able to say that it didn't get done "right",
and that will appear as if they are more interested in policy than the
already achieved goals. But, that's inherent to matters that are referred to
as "academic disagreement", I believe. :)

--
2. That which causes joy or happiness.

On Sun, Mar 11, 2007 at 04:46:58PM -0700, Josh Berkus wrote:
> > It would take eleven Debian developers making a resolution within the
> > project in order to get an injuction on a decision by the leader.
> > (That's how I read Debian Constitution paragraphs 4.2.2.2 + 4.2.7.)
>
> Yes, but I can see other interpretations of that article.

Which ones?

If there is disagreement in the interpreting of the constitution,
the project secretary adjudicates, and that can happen ASAP I guess.

--
2. That which causes joy or happiness.

On Sun, Mar 11, 2007 at 04:35:19PM -0700, Joshua D. Drake wrote:
> As an outsider, it appears that Debian is more interested in policy than
> actually achieving goals.

Debian's a large organisation that has very few rules on how its members
behave -- the concerns here have been raised by a number of members of
Debian and SPI including a member of the SPI board. They haven't been
raised by Debian as a whole or Debian's representative to SPI, however.

The people who're interested in policy like this will naturally be the
ones that discuss it; the people who're interested in achieving other
goals will equally naturally be off doing that.

Cheers,
aj

"Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote: [...]
> Any thoughts that Debian should not have to provide an exact number of
> authoritative contacts with published information of who those contacts
> should be immediately laughed out of the building. [...]

Any suggestion that SPI should tell the Debian project who may make
decisions about its resources should fail the laugh test!

Theodore Tso <tytso(at)mit(dot)edu> wrote: [...]
> Hence, in order for SPI to protect itself, it is best from SPI's point
> of view to have a very strictly defined interface with which it
> interacts with its sub-projects, much like a bank has a strictly
> defined interface with its customers --- and for the same reasons.

Yes, SPI should name contacts like a bank does, but must also - like a
bank does - recognise that the authority of those contacts only
extends so far and so long as the "account holder" permits it.

> The legal exposure, not to mention the exposure to vast debian mailing
> list flame wars to SPI board members who are not otherwise obligated
> to be on various Debian mailing list, would be enormous.

If there are legal implications of stating a mechanism for making SPI
aware of project decisions, then I hope that a/ SPI will take legal
advice from their usual expert(s); and b/ it could be solved by simply
omitting clause 8.

Josip Rodin <joy(at)entuzijast(dot)net> wrote: [...]
> However, the text didn't really go far enough with that - what if the SPI
> board is duly informed about something like that, but it still decides to go
> through with transactions because it doesn't think they're a problem?

I expect someone (donor, other project decision-maker) could complain
and win legally, with all sorts of bad consequences for all SPI projects.

> Anyway, do other associated projects implement any similar safeguards?

I don't think other projects are sitting on as much money as debian
and have such a potential for a wide range of views among
decision-makers, so it's probably not as grave.

Again, please keep clause 5 of 2007-02-28.iwj.1 and not change the
debian funds into DPL funds, and I'm amazed that this is contraversial.

Regards,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

MJ Ray wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote: [...]
>> Any thoughts that Debian should not have to provide an exact number of
>> authoritative contacts with published information of who those contacts
>> should be immediately laughed out of the building. [...]
>
> Any suggestion that SPI should tell the Debian project who may make
> decisions about its resources should fail the laugh test!

You misunderstand my point. I don't care in any way how Debian makes its
decisions.

The only thing I care about is that SPI only accept a defined number of
roles, preferably two or less that are allowed to communicate those
decisions.

If Debian finds that their roles are cutting the bill, Debian needs to
deal with it, not SPI. Debian could deal with it, simply by holding a
vote, removing the person and having another vote to place a different
person in the role.

Now there is an opportunity for abuse here, so in Debian's case, it
would make sense to have an overriding figure which I believe is the DPL ?

Which in turn means you don't want the DPL to be the primary contact.

However all of that is up to Debian.

> Theodore Tso <tytso(at)mit(dot)edu> wrote: [...]
>> Hence, in order for SPI to protect itself, it is best from SPI's point
>> of view to have a very strictly defined interface with which it
>> interacts with its sub-projects, much like a bank has a strictly
>> defined interface with its customers --- and for the same reasons.
>
> Yes, SPI should name contacts like a bank does, but must also - like a
> bank does - recognise that the authority of those contacts only
> extends so far and so long as the "account holder" permits it.

That is no different than the SPI today.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Ian,

> If there are legal implications of stating a mechanism for making SPI
> aware of project decisions, then I hope that a/ SPI will take legal
> advice from their usual expert(s); and b/ it could be solved by simply
> omitting clause 8.

Would you agree to omit clause 8? I have no problem with the rest of your
proposal if you take that out.

--
Josh Berkus
PostgreSQL Project
Core Team Member
(any opinions expressed are my own)

"Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
> The only thing I care about is that SPI only accept a defined number of
> roles, preferably two or less that are allowed to communicate those
> decisions.

Why? SPI is not proposing to do that for OpenOffice.org. Only the
vague term "liaison" is specified, and it is proposed that SPI
recognises an OpenOffice.org council process at an external URL.

Really, is resolving that:

The OpenOffice.org liason to SPI will be elected by the
OpenOffice.org community council according to the process documented
at http://council.openoffice.org/advisor-process.html. The initial
liason will be Louis Suarez-Potts.

significantly different from

The Debian Constitution (http://www.debian.org/devel/constitution),
and the persons holding the roles it defines and acting according to
that Constitution, are recognised by SPI as ultimately authoritative
regarding decisions of the Debian Project. [...] The Board will
recognise decisions, statements and delegations made by the Debian
Project Leader, currently Anthony Towns, as made on behalf of
Debian.

except using a few fewer words? The rest of the proposed debian
declaration is simply factual or request, after all.

> If Debian finds that their roles are cutting the bill, Debian needs to
> deal with it, not SPI. Debian could deal with it, simply by holding a
> vote, removing the person and having another vote to place a different
> person in the role.

I think that would be changing the person, not changing the role.

If SPI is awkward enough to name particular roles in debian and not
recognise the debian project process, then changing the roles will
require SPI to pass another resolution. SPI is considering
recognising OpenOffice.org's process - why is it a problem to
recognise debian's process?

Regards,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

MJ,

> Why? SPI is not proposing to do that for OpenOffice.org. Only the
> vague term "liaison" is specified, and it is proposed that SPI
> recognises an OpenOffice.org council process at an external URL.

Actually, we are. OpenOffice.org will have *exactly one* represenative to
SPI, known as the Liason on our side and the Advisor on theirs.

> The Debian Constitution (http://www.debian.org/devel/constitution),
> and the persons holding the roles it defines and acting according to
> that Constitution, are recognised by SPI as ultimately authoritative
> regarding decisions of the Debian Project. [...] The Board will
> recognise decisions, statements and delegations made by the Debian
> Project Leader, currently Anthony Towns, as made on behalf of
> Debian.

I don't have a problem with that (Ian's) version. Like with OOo, it
defines *eactly one* point of contact, and further paragraphs define the
Debian Secretary (and only the secretary) as the "backup" contact. My
problem is with clause 8, which could be read to open up offical contact
to 100% of Debian members, effectively giving Debian 300 liasons, and
requiring the SPI board to adjuticate any dispute between them.

This is not something which I, as treasurer and board member, can deal
with.

> If SPI is awkward enough to name particular roles in debian and not
> recognise the debian project process, then changing the roles will
> require SPI to pass another resolution. SPI is considering
> recognising OpenOffice.org's process - why is it a problem to
> recognise debian's process?

Again, as long as Debian designates *exactly one* person who can request
funds, etc., I don't care how that person is selected. What I'm going to
vote against is any resolution which suggests that that multiple Debian
people could independantly make finanicial and/or legal requests of SPI in
conflict with each other.

--
--Josh

Josh Berkus
Treasurer
Software in the Public Interest, Inc.
treasurer(at)spi-inc(dot)org

On Tue, Mar 13, 2007 at 09:10:00AM -0700, Josh Berkus wrote:
> Would you agree to omit clause 8? I have no problem with the rest of your
> proposal if you take that out.

(It's actually Ian's proposal.)

Josh, would you agree that the part of section 8 that talks about 'any
dispute regarding decisions' is the problem, and not the entire section 8?
I pointed this out in an earlier mail, but it went under the radar, it seems.

The bit about 'any change regarding authority' is worth keeping IMO.
Authority is strictly defined under the Debian Constitution, and the said
document is introduced already in section 5. Indeed, if the extra stuff
about disputes is removed, section 8 becomes just a logical extension
of section 5.

--
2. That which causes joy or happiness.

Josh Berkus <josh(at)postgresql(dot)org> wrote:
> MJ,
> > Why? SPI is not proposing to do that for OpenOffice.org. Only the
> > vague term "liaison" is specified, and it is proposed that SPI
> > recognises an OpenOffice.org council process at an external URL.
>
> Actually, we are. OpenOffice.org will have *exactly one* represenative to
> SPI, known as the Liason on our side and the Advisor on theirs.

That's the case initially, but is there any requirement that the
liaison is one person, or that SPI would ignore other valid requests
from OpenOffice.org just because the liaison walks off the map?

Through the associated project framework, the resolution commits SPI
to "honour" OpenOffice.org's "rules and procedures about its
relationship with SPI". As such, SPI is rightly not restricting
OpenOffice.org to a limited one-person interface.

ISTR that even PostgreSQL's verbose associated project resolution
didn't limit PostgreSQL to having exactly one liaison.

[...]
> > If SPI is awkward enough to name particular roles in debian and not
> > recognise the debian project process, then changing the roles will
> > require SPI to pass another resolution. SPI is considering
> > recognising OpenOffice.org's process - why is it a problem to
> > recognise debian's process?
>
> Again, as long as Debian designates *exactly one* person who can request
> funds, etc., I don't care how that person is selected. What I'm going to
> vote against is any resolution which suggests that that multiple Debian
> people could independantly make finanicial and/or legal requests of SPI in
> conflict with each other.

Why? SPI already has policies about dealing with disputes and
conflicts within associated projects. They can all make the requests,
but probably most would be invalid. Adjudication is likely to be
fairly simple, asking the project secretary to interpret the
constitution and say which (if any) decisions are valid. If it's
urgent, the DPL wins anyway. That's already handled by SPI's
policies, isn't it?

This special-for-debian "exactly one" requirement is improper in at
least two ways:

1. If SPI designated exactly one person in debian, instead of relying
on debian's resolutions and SPI's policies to deal with it, SPI would
change debian's internal decision-making process. It's also a (wrong
IMO) suggestion that SPI's policies on associated project conflicts
are inadequate.

2. SPI members had a chance to comment and require a special debian
SPI liaison when debian was updating its constitution about this a few
months ago. ISTR that some people explicitly asked that we wait for
any SPI board view (which didn't come AFAICR). But all that probably
wouldn't have stopped the possibility that DDs could reverse decisions
of the liaison.

Finally, I'd swear that Josh Berkus has voted to approve projects
without specifying only one allowed person before (the Corporate ->
Minutes section of www.spi-inc.org is very empty, so how to check?)
but I guess we'll now see him voting against all future Associated
Project resolutions which don't specify only one allowed person,
including the OpenOffice.org one, or changing his position.

Regards,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Webmaster/web developer, statistician, sysadmin, online shop maker,
developer of koha, debian, gobo, gnustep, various mail and web s/w.
Workers co-op @ Weston-super-Mare, Somerset http://www.ttllp.co.uk/

On Wed, Mar 14, 2007 at 01:04:52PM +0000, MJ Ray wrote:
> Why? SPI already has policies about dealing with disputes and
> conflicts within associated projects. They can all make the requests,
> but probably most would be invalid. Adjudication is likely to be
> fairly simple, asking the project secretary to interpret the
> constitution and say which (if any) decisions are valid. If it's
> urgent, the DPL wins anyway. That's already handled by SPI's
> policies, isn't it?
>
> This special-for-debian "exactly one" requirement is improper in at
> least two ways:

I think people have been say "at most two", not "exactly one".

And the two IMHO should be the DPL and the Debian Secretary. Note
that there is a huge amount of trust put into the Debian Secretary,
since he or she is the person who runs the elections and the GR's. So
if Debian ever degenerates to the point where the majority of its
members don't trust the Debian Secretary, it has major problems
anyway, and it either (a) represents a hole in the Debian
Constitution, or (b) just an known issue for which fixing would
represent over-engineering.

So my proposed interface would be the DPL designates the identity of
the Debian Secretary to the SPI, and the Debian Secretary designates
the identity of the DPL to the SPI. Note that Debian invests a huge
amount of trust in these individuals in any case, and if both of them
are in conspiring against the wishes of everyone else in Debian (and
how would you prove it, given that the mere presence of a vocal
minority doesn't mean that the majority of the DD's really feel that
way, and if you don't trust the person running the GR's and Elections,
you're kind of toast anyway).

It would be easier if Debian had an elected board with rotating terms
instead of a single DPL, such that if there was any kind of question,
in cases of extreme emergency, at least the SPI board could interview
the elected board and try to sort what is going on. But Debian's
governance structure (which simply doesn't scale to the size that
Debian has grown into --- there are now 1000 DD's that could currently
approach the SPI board and try to claim that the SPI should pay
attention to their pet grievence) simply doesn't allow that. But
that's a matter for Debian to figure out, at some point (hopefully!).

- Ted

MJ Ray wrote:
> Josh Berkus <josh(at)postgresql(dot)org> wrote:
>> MJ,
>>> Why? SPI is not proposing to do that for OpenOffice.org. Only the
>>> vague term "liaison" is specified, and it is proposed that SPI
>>> recognises an OpenOffice.org council process at an external URL.
>> Actually, we are. OpenOffice.org will have *exactly one* represenative to
>> SPI, known as the Liason on our side and the Advisor on theirs.
>
> That's the case initially, but is there any requirement that the
> liaison is one person, or that SPI would ignore other valid requests
> from OpenOffice.org just because the liaison walks off the map?
>
> Through the associated project framework, the resolution commits SPI
> to "honour" OpenOffice.org's "rules and procedures about its
> relationship with SPI". As such, SPI is rightly not restricting
> OpenOffice.org to a limited one-person interface.
>
> ISTR that even PostgreSQL's verbose associated project resolution
> didn't limit PostgreSQL to having exactly one liaison.

liaison is singular.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Tue, Mar 13, 2007 at 07:37:07PM +0100, Josip Rodin wrote:
> Josh, would you agree that the part of section 8 that talks about 'any
> dispute regarding decisions' is the problem, and not the entire section 8?
> I pointed this out in an earlier mail, but it went under the radar, it seems.
>
> The bit about 'any change regarding authority' is worth keeping IMO.
> Authority is strictly defined under the Debian Constitution, and the said
> document is introduced already in section 5. Indeed, if the extra stuff
> about disputes is removed, section 8 becomes just a logical extension
> of section 5.

I like that suggestion. I have an amendment to Ian's proposal which is a
slight improvement on that which avoids the "300 liaisons" issue. Please
note that my amendment uses the paragraph numbering in the draft
resolution version on the SPI website here:
http://www.spi-inc.org/secretary/draft-resolutions/2007-02-28-iwj.1.html

--- cut here ---
Replace paragraphs 3 through 5 of the non-whereas portion of Ian's
resolution with the following:

3. The SPI Board does not intend to monitor the Debian mailing lists.
The Board will recognise decisions, statements, and delegations made by
the Debian Project Leader, currently Anthony Towns, as made on behalf of
Debian, except to the extent this assumption is contradicted by
information to the SPI Board by the Debian Project Secretary in
accordance with paragraph 4.

4. The Board specifically asks that the Debian Project Secretary inform
the SPI Board of any Debian General Resolutions which might be relevant
to SPI, including any proposals to put spending on hold, as well as any
dispute or change regarding the identity or authority of the Debian
Project Leader.

5. The Board relies on Debian Developers and others to ensure the Board
is made aware of any situations in which the Debian Project Leader and
the Debian Project Secretary disagree on the identity or authority of
the Debian Project Secretary.
--- cut here ---

Ian, will you be willing to accept these changes? I think it keeps most
of your intent while satisfying most of the critics. The set of topics
about which the Board would be needing to act in response to
communications from "Debian Developers and others" with this revision is
simply to resolve identity and authority crises reflecting a breakdown
of the system of one normal and one backup contact, and in no other
situation. It also doesn't seem to upset the power structure in Debian
between the DPL and the Secretary as per the Constitution, given that
the Secretary is the ultimate interpreter of the Constitution and
election results, but the DPL is the primary external representative of
Debian.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Jimmy Kaplowitz writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> Replace paragraphs 3 through 5 of the non-whereas portion of Ian's
> resolution with the following:

I think this is going in a reasonable direction but I still have a
slight problem with it, which is that it shifts the dictatorship from
the DPL to the Secretary. You say

> the Secretary is the ultimate interpreter of the Constitution

but in fact they are not empowered off their own bat to interpret the
constitution however they like. There has to be a dispute.

Having seen how the power to interpret the constitution has been used,
with hindsight I would not have vested it in the Secretary; the TC
would probably have been a better choice since it (a) consists of
several different people and (b) avoids some of the situations which
look rather too much like self-dealing.

> 5. The Board relies on Debian Developers and others to ensure the Board
> is made aware of any situations in which the Debian Project Leader and
> the Debian Project Secretary disagree on the identity or authority of
> the Debian Project Secretary.

Would you accept

5. The Board relies on Debian Developers and others to ensure the Board
is made aware of any situations where there is disagreement on the
identity or authority of the Debian Project Leader or the Debian
Project Secretary.

?

Note that we're only asking DD's to _make the board aware_. After
that they're not supposed to keep bothering us - we can say `thank you
we are aware, now we will consider it and there is no need to mail us
any more'.

If we're worried about people CCing the board on hideous flamewars we
can explicitly ask them not to do that. For example:

3. The SPI Board does not intend to monitor the Debian mailing lists
and does not wish to be copied on any discussions of political
disputes carried out on those lists. ....

Ian.

On Fri, Mar 16, 2007 at 04:39:05PM +0000, Ian Jackson wrote:
> I think this is going in a reasonable direction but I still have a
> slight problem with it, which is that it shifts the dictatorship from
> the DPL to the Secretary. You say
>
> > the Secretary is the ultimate interpreter of the Constitution
>
> but in fact they are not empowered off their own bat to interpret the
> constitution however they like. There has to be a dispute.

Well, my wording still leaves the DPL as primary decision communicator,
as is appropriate. In those cases where the Secretary's assertions are
acted upon by SPI in contradiction of the DPL's assertions, there
clearly is a dispute at least between those two DDs, and therefore the
Secretary is empowered to interpret the constitution. In cases where the
Secretary's assertions do not contradict those of the DPL, I don't see
how my wording gives the Secretary any more dictatorial powers than in
your wording. My revisions to paragraph 5 were also intended to be a
counterbalance on the Secretary.

> Having seen how the power to interpret the constitution has been used,
> with hindsight I would not have vested it in the Secretary; the TC
> would probably have been a better choice since it (a) consists of
> several different people and (b) avoids some of the situations which
> look rather too much like self-dealing.

That's a moot point for this discussion, though you could always propose
a constitutional amendment within Debian.

> Would you accept
>
> 5. The Board relies on Debian Developers and others to ensure the Board
> is made aware of any situations where there is disagreement on the
> identity or authority of the Debian Project Leader or the Debian
> Project Secretary.

That opens up a denial of service attack where if any two individuals
(whether DDs or media people or whoever else) disagree on what the DPL
has the authority to do, the Board is inviting emails on every such
occasion, and we could get overwhelmed with emails we theoretically
requested if someone wants to be mischievous. Even if you restrict it to
only disagreement among DDs, the problem doesn't get much better,
because there will always be at least two DDs who disagree on the
authority of the DPL or the Secretary.

My wording was specifically intended to resolve those conflicts between
the two recognized Debian contacts to SPI for which the default
resolution (i.e., Secretary wins) would be unfair. I'd prefer if SPI
didn't have to at least contemplate every disagreement among DDs or the
public that doesn't affect SPI in any way.

> Note that we're only asking DD's to _make the board aware_. After
> that they're not supposed to keep bothering us - we can say `thank you
> we are aware, now we will consider it and there is no need to mail us
> any more'.

Yes, I realize this. It's still a DoS because almost no group of the
size of Debian (or larger) will be ever free of disagreements on these
matters.

> If we're worried about people CCing the board on hideous flamewars we
> can explicitly ask them not to do that. For example:
>
> 3. The SPI Board does not intend to monitor the Debian mailing lists
> and does not wish to be copied on any discussions of political
> disputes carried out on those lists. ....

I dislike flamewars as much as anyone, but there might be legitimate
circumstances for such a CC buried within all the flaming, so I'd prefer
to leave this out.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

On Fri, Mar 16, 2007 at 01:09:47PM -0400, Jimmy Kaplowitz wrote:
> > Would you accept
> >
> > 5. The Board relies on Debian Developers and others to ensure the Board
> > is made aware of any situations where there is disagreement on the
> > identity or authority of the Debian Project Leader or the Debian
> > Project Secretary.
>
> That opens up a denial of service attack where if any two individuals
> (whether DDs or media people or whoever else) disagree on what the DPL
> has the authority to do, the Board is inviting emails on every such
> occasion [...]

What I said is true but I now realize missed the point of your wording:
you added the DPL to the list of people whose identity and authority we
might want DDs and others to tell us about. Here's a revised version
of that paragraph that I think satisfies your concerns without creating
a meaningfully likely DoS opportunity:

5. The Board relies on Debian Developers and others to ensure that the
Board is made aware of any situations where there is disagreement among
Debian Developers on the identity of the Debian Project Leader or the
Debian Project Secretary, and situations where the Debian Project Leader
and Debian Project Secretary disagree on the authority held by either of
them.

Does this work for you in combination with the rest of my amendment to
your resolution?

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Jimmy Kaplowitz writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> My wording was specifically intended to resolve those conflicts between
> the two recognized Debian contacts to SPI for which the default
> resolution (i.e., Secretary wins) would be unfair. I'd prefer if SPI
> didn't have to at least contemplate every disagreement among DDs or the
> public that doesn't affect SPI in any way.

Perhaps this problem should be addressed by saying we're only
interested in disagreements that are relevant to SPI.

> That opens up a denial of service attack where if any two individuals
> (whether DDs or media people or whoever else) disagree on what the DPL
> has the authority to do, the Board is inviting emails on every such
> occasion, and we could get overwhelmed with emails we theoretically
> requested if someone wants to be mischievous. [...]

If that happens we can un-request them! I don't think this is likely
to be a serious problem.

> I dislike flamewars as much as anyone, but there might be legitimate
> circumstances for such a CC buried within all the flaming, so I'd prefer
> to leave this out.

I can't see any situation where the SPI board should be CC'd on a
Debian flamewar. BCC on a particular message perhaps, or have a
particular message forwarded, yes. But a CC on the argument itself
leads to just the same kind of dysfunction as the corporate types who
CC the CEO on every slight controversial mail they send - everyone
else must now also CC the same people.

Ian.

Jimmy Kaplowitz writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> 5. The Board relies on Debian Developers and others to ensure that the
> Board is made aware of any situations where there is disagreement among
> Debian Developers on the identity of the Debian Project Leader or the
> Debian Project Secretary, and situations where the Debian Project Leader
> and Debian Project Secretary disagree on the authority held by either of
> them.

Really I think this is hair-splitting which will do no good if we have
a real flamer idiot DoS type. The reason I'm resisting it is because
it gives the impression that the SPI board thinks it's not supposed to
read the constitution and make up its own mind - and it is IMO
supposed to do that.

Ian.

On Fri, Mar 16, 2007 at 05:29:12PM +0000, Ian Jackson wrote:
> > Board is made aware of any situations where there is disagreement among
> > Debian Developers on the identity of the Debian Project Leader or the
> > Debian Project Secretary, and situations where the Debian Project Leader
> > and Debian Project Secretary disagree on the authority held by either of
> > them.
>
> Really I think this is hair-splitting which will do no good if we have
> a real flamer idiot DoS type. The reason I'm resisting it is because
> it gives the impression that the SPI board thinks it's not supposed to
> read the constitution and make up its own mind - and it is IMO
> supposed to do that.

I have to pick a level of risk to worry about, and I'm much less worried
about the risk of people inventing disagreements about the DPL's
identity for sake of DoSing the board than I am about the very real
likelihood that there will always be DDs who dissent from the majority
view of the scope of the DPL's authority. I also don't care for this
purpose if non-DDs are mistaken about any of the above.

And, I don't see how this gives the impression that the SPI board
wouldn't read the constitution in case of a disagreement on identity or
authority of our recognized decision communicators, after being notified
about the disagreement. It does give the impression that the board
wouldn't take the initiative to proactively check every request from the
DPL or Secretary with its own reading of the constitution, but that is a
very reasonable stance for the board to take.

SPI should only interpret projects' internal documents when it can't
feel certain of the validity of the interpretations it has been given by
its designated contacts in the projects. Do you want to have to read
PostgreSQL and OpenOffice.org's internal governing documents to verify
that all of their liaisons' requests to SPI are properly authorized in
the absence of a reason to doubt that being the case? I certainly don't,
and our treasurer most definitely doesn't.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Jimmy Kaplowitz writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> I have to pick a level of risk to worry about, and I'm much less worried
> about the risk of people inventing disagreements about the DPL's
> identity for sake of DoSing the board than I am about the very real
> likelihood that there will always be DDs who dissent from the majority
> view of the scope of the DPL's authority. I also don't care for this
> purpose if non-DDs are mistaken about any of the above.

Let me give an example scenario on which we might be disagreeing:

Supposing the DPL and Secretary ask us to spend some money, and while
we're double-checking or getting around to a board vote or whatever, a
bunch of developers get a quorum for a put-on-hold; but suppose the
Secretary drags her feet for whatever reason (perhaps because she
agrees with the decision, or perhaps just because she's busy).

Now I would like one of those developers to mail the SPI board and say
`we have enough people to put this decision on hold; here are their
names and references to the procedure we're following'.

But note that your criteria (the DPL and Secretary disagree about each
others' authority or identity) are not met.

Perhaps there's another way to address your DoS concern. What we
really want is to make sure that we're told about disputes that are
(a) relevant to us and which (b) we don't know about already.
Obviously if we already know about a dispute then we don't want to be
told again and I think being told once doesn't constitute a DoS.

So perhaps:

(n). The SPI Board relies on Debian Developers and others to ensure
that if the validity of a Debian decision relevant to SPI is
disputed, the Board's attention is drawn to the existence of the
dispute, if the Board might otherwise remain unaware of it.

So we only ask for notification of the existence of the dispute and
only if we didn't know about it anyway.

Ian.

On Fri, Mar 16, 2007 at 01:36:57PM -0400, Jimmy Kaplowitz wrote:
> I have to pick a level of risk to worry about, and I'm much less worried
> about the risk of people inventing disagreements about the DPL's
> identity for sake of DoSing the board than I am about the very real
> likelihood that there will always be DDs who dissent from the majority
> view of the scope of the DPL's authority. I also don't care for this
> purpose if non-DDs are mistaken about any of the above.

The only thing which the SPI should care about with respect to the
authority held by the DPL and the Secretary is their authority with
respect to the requests made to the SPI. And these authorities is
somethign which can and should be very clearly enumerated.

- Ted

On Fri, Mar 16, 2007 at 05:54:47PM +0000, Ian Jackson wrote:
> Supposing the DPL and Secretary ask us to spend some money, and while
> we're double-checking or getting around to a board vote or whatever, a
> bunch of developers get a quorum for a put-on-hold; but suppose the
> Secretary drags her feet for whatever reason (perhaps because she
> agrees with the decision, or perhaps just because she's busy).
>
> Now I would like one of those developers to mail the SPI board and say
> `we have enough people to put this decision on hold; here are their
> names and references to the procedure we're following'.

Fair point. I shouldn't have restricted to DPL<->Secretary disagreements
only. That complaint should be encouraged if the Secretary is viewed by
some DDs as exceeding her authority by delaying, or not serving SPI's
needs by communicating with us in a timely manner.

> (n). The SPI Board relies on Debian Developers and others to ensure
> that if the validity of a Debian decision relevant to SPI is
> disputed, the Board's attention is drawn to the existence of the
> dispute, if the Board might otherwise remain unaware of it.

How about this:

5. The Board relies on Debian Developers and others to ensure that the
Board is made aware of Debian decisions relevant to SPI that are not
communicated to the Board in a timely manner by the Debian Project
Leader or the Debian Project Secretary; of disagreement among Debian
developers regarding the identity of the Debian Project Leader or the
Debian Project Secretary; and of disagreement among Debian developers as
to the authority held by either of those two Debian officials, but only
insofar as this authority is relevant to SPI. The Board requests that
those who notify it of decisions or disagreements in accordance with
this paragraph take reasonable efforts to look for prior notifications
to the Board on the same topic, and that the Board not be notified again
if the new notification would be substantially the same as a previous
one.

This avoids the inaction loophole you were mentioning, and adds the
relevance and novelty criteria. Does this work for you (and everyone
else who's still reading)?

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Jimmy Kaplowitz writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> 5. The Board relies on Debian Developers and others to ensure that the
> Board is made aware of Debian decisions relevant to SPI that are not
> communicated to the Board in a timely manner by the Debian Project
> Leader or the Debian Project Secretary; of disagreement among Debian
> developers regarding the identity of the Debian Project Leader or the
> Debian Project Secretary; and of disagreement among Debian developers as
> to the authority held by either of those two Debian officials, but only
> insofar as this authority is relevant to SPI. The Board requests that
> those who notify it of decisions or disagreements in accordance with
> this paragraph take reasonable efforts to look for prior notifications
> to the Board on the same topic, and that the Board not be notified again
> if the new notification would be substantially the same as a previous
> one.
>
> This avoids the inaction loophole you were mentioning, and adds the
> relevance and novelty criteria. Does this work for you

Yes, thanks.

> (and everyone else who's still reading)?

*snort* I think we've bored them away by now ...

Ian.

Ian Jackson wrote:
> Jimmy Kaplowitz writes ("Re: Draft resolution formalising Debian's Associated Project status"):
>> 5. The Board relies on Debian Developers and others to ensure that the
>> Board is made aware of Debian decisions relevant to SPI that are not
>> communicated to the Board in a timely manner by the Debian Project
>> Leader or the Debian Project Secretary; of disagreement among Debian
>> developers regarding the identity of the Debian Project Leader or the
>> Debian Project Secretary; and of disagreement among Debian developers as
>> to the authority held by either of those two Debian officials, but only
>> insofar as this authority is relevant to SPI. The Board requests that
>> those who notify it of decisions or disagreements in accordance with
>> this paragraph take reasonable efforts to look for prior notifications
>> to the Board on the same topic, and that the Board not be notified again
>> if the new notification would be substantially the same as a previous
>> one.
>>
>> This avoids the inaction loophole you were mentioning, and adds the
>> relevance and novelty criteria. Does this work for you
>
> Yes, thanks.
>
>> (and everyone else who's still reading)?
>
> *snort* I think we've bored them away by now ...
>

No but I don't want to start up another issue ;)

Joshua D. Drake

> Ian.
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

All,

Given that we say in point (1) that the authority of the DPL & Secretary
derive from the Debian constitution, I really don't see why (5) is necessary
at all. The only "dispute of authority" I'm willing to accept will be one
grounded in the constitution, and if there is such a dispute we can take it
as assumed that some DD or Board member will bring it up.

No matter how we re-write (5), it's superfluous and an invitation to DD's to
argue with the DPL on the SPI-lists. Again, I would like it to be simply
removed.

--
Josh Berkus
PostgreSQL Project
Core Team Member
(any opinions expressed are my own)

Josh Berkus wrote:
> All,
>
> Given that we say in point (1) that the authority of the DPL & Secretary
> derive from the Debian constitution, I really don't see why (5) is necessary
> at all. The only "dispute of authority" I'm willing to accept will be one
> grounded in the constitution, and if there is such a dispute we can take it
> as assumed that some DD or Board member will bring it up.
>
> No matter how we re-write (5), it's superfluous and an invitation to DD's to
> argue with the DPL on the SPI-lists. Again, I would like it to be simply
> removed.

O.k. since it has come back up :). I pretty much have to agree with Josh
here. This is not the SPIs problem or business. If the DPL & Secretary
are bound by the Debian constitution, so are the DDs.

Let Debian deal with it, and report (via the Liaison) to SPI the motion
etc... If the Secretary drags his/her feet, then the DDs can form a
quorum to recall her yes?

...

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Joshua D. Drake writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> Let Debian deal with it, and report (via the Liaison) to SPI the motion
> etc... If the Secretary drags his/her feet, then the DDs can form a
> quorum to recall her yes?

It is exactly this attitude which shows why this extra paragraph is
needed.

Josh Berkus says it's not needed because the DD's will tell us anyway.
But Joshua says it's wrong because we won't/shouldn't listen to the
DD's and should pay attention only to the liason !

As previously discussed, SPI has already committed to honouring
Debian's governance structures. And that includes honouring decisions
properly made _even if the appointed liason fails to pass them on_.

(Also, saying "DDs can ... remove the Liason" is pointless if the
decision to remove the liason is to be passed on by the liason.)

I'm sorry to have to do this but I am adamantly opposed to any motion
of this form which does not have an explict recognition of this
principle:

If the Debian postholders do not carry out their responsibilities to
properly convey Debian's decisions to us, we (a) want DDs to tell us
about this and (b) we will act on those decisions even if the
postholders prevaricate or obstruct.

Jimmy, would you write up a draft resolution with that paragraph 5 as
you last wrote it ?

If the Board passes an amendment goes to remove that paragraph then I
will vote against the whole motion. If the motion passes anyway then
I will have to consider what my available options are for ensuring
that SPI will honour its commitments to Debian.

As far as I can see it the only option that might actually work would
be to use Debian's processes to pass a formal demand of some kind to
SPI, or perhaps to explicitly appoint a favourable person as the
representative to SPI on this topic.

But I think we've got quite enough of a political shitstorm in Debian
as it is and putting me in this position is not going to lead to the
quiet life you're apparently aiming for!

Ian.

Ian Jackson wrote:
> Joshua D. Drake writes ("Re: Draft resolution formalising Debian's Associated Project status"):
>> Let Debian deal with it, and report (via the Liaison) to SPI the motion
>> etc... If the Secretary drags his/her feet, then the DDs can form a
>> quorum to recall her yes?
>
> It is exactly this attitude which shows why this extra paragraph is
> needed.
>
> Josh Berkus says it's not needed because the DD's will tell us anyway.

Well I certainly don't think we should rely on non position holding
members (the information is great, thank you but we need an
authoritative point).

> But Joshua says it's wrong because we won't/shouldn't listen to the
> DD's and should pay attention only to the liason !

Well let me be clear and state that I am assuming that Debian has
control of its structure.

>
> As previously discussed, SPI has already committed to honouring
> Debian's governance structures. And that includes honouring decisions
> properly made _even if the appointed liason fails to pass them on_.
>
> (Also, saying "DDs can ... remove the Liason" is pointless if the
> decision to remove the liason is to be passed on by the liason.)

My assumption is that it works like this:

Liaison does something bad
DD removes Liaison
DD elects new Liaison
New Liaison informs SPI of decision, and shows motion where passed
(however that is done.

Of course there is the question of what happens *in between* and thus:

If the old Liaison does something *really* bad, New Liaison requests
funds to take legal action against old bad mojo Liaison.

>
>
> I'm sorry to have to do this but I am adamantly opposed to any motion
> of this form which does not have an explict recognition of this
> principle:
>
> If the Debian postholders do not carry out their responsibilities to
> properly convey Debian's decisions to us, we (a) want DDs to tell us
> about this and (b) we will act on those decisions even if the
> postholders prevaricate or obstruct.

I could probably live with (b), (a) to me is a no op. Who is to
determine if what the DDs tell us is valid, appropriate or even necessary?

Just look at the whole Dunc Tank debacle..

>
>
> But I think we've got quite enough of a political shitstorm in Debian
> as it is and putting me in this position is not going to lead to the
> quiet life you're apparently aiming for!

I am not looking for a quiet life, if that was the case.. I would be
making 150k a year somewhere as an employee not spending my time here
;). I am however trying to insure a level of sanity.

Sincerely,

Joshua D. Drake

>
>
> Ian.

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Fri, Mar 16, 2007 at 11:54:10AM -0700, Joshua D. Drake wrote:
> Let Debian deal with it, and report (via the Liaison) to SPI the motion
> etc... If the Secretary drags his/her feet, then the DDs can form a
> quorum to recall her yes?

They can actually only pass a general resolution to appoint a new
secretary if there is a disagreement between the project leader and the
incumbent secretary. (cf. Paragraph 4.1.7). So if the project leader is
happy with the secretary, DDs cannot recall the project secretary
(without first recalling the project leader and replacing him via a
nine-week election). However, if a general resolution does get
attempted, it is the Secretary and only the Secretary who runs votes,
determines method of balloting, decides issues of procedure, etc.
Therefore, if the Secretary drags his/her feet on the vote and is
uncooperative about agreeing to a replacement Secretary, there's really
nothing to be done. It's definitely a flaw in the system.

As for the broader issue at hand, I very much agree with Ian that if the
Debian liaisons to SPI don't do their job properly and timely in
conveying decisions relevant to SPI, it's important for DDs to notify
us, both to protect Debian's decision-making integrity and for SPI's
own due diligence in conducting transactions. Which is why paragraph 5
is a useful encouragement.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Joshua D. Drake writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> Well I certainly don't think we should rely on non position holding
> members (the information is great, thank you but we need an
> authoritative point).

The authoritative point is _as defined in the constitution_ which is a
public document which we have promised to follow. And every DD has
certain powers; in particular a certain number of them can cause a
decision to be frozen.

> > If the Debian postholders do not carry out their responsibilities to
> > properly convey Debian's decisions to us, we (a) want DDs to tell us
> > about this and (b) we will act on those decisions even if the
> > postholders prevaricate or obstruct.
>
> I could probably live with (b), (a) to me is a no op. Who is to
> determine if what the DDs tell us is valid, appropriate or even necessary?
>
> Just look at the whole Dunc Tank debacle..

I don't think Dunc Tank was a debacle from SPI's point of view. The
only reason we had any serious argument about at all was this very
point that we're arguing about again now.

Obviously there was lots and lots of discussion in Debian but I don't
see the problem really.

Ian.

>
> As for the broader issue at hand, I very much agree with Ian that if the
> Debian liaisons to SPI don't do their job properly and timely in
> conveying decisions relevant to SPI, it's important for DDs to notify
> us, both to protect Debian's decision-making integrity and for SPI's
> own due diligence in conducting transactions. Which is why paragraph 5
> is a useful encouragement.

Well again, not so much opposed to the idea of them giving us
information as much as us actually acting on it.

15 DDs stood in a room and cried foul.

What does that mean?

100 DDs stood in a room and cried foul.

What does that mean?

There are over 300 DDs aren't there?

Sincerely,

Joshua D. Drake

>
> - Jimmy Kaplowitz
> jimmy(at)spi-inc(dot)org

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Fri, Mar 16, 2007 at 07:08:22PM +0000, Ian Jackson wrote:
> Jimmy, would you write up a draft resolution with that paragraph 5 as
> you last wrote it ?

Here is the latest draft agreed upon by Ian and me in this thread, which I
hereby propose for today's meeting:

--- cut here ---

2007-02-28.iwj.1.jrk.1

Formally recording Debian's status as an Associated Project
Whereas;

1. Debian is a substantial and significant Free Software project;
2. SPI and Debian regard Debian as an SPI Associated Project; however
3. The detailed terms of the Association have not been formally stated by the SPI Board in the manner now customary.

The SPI Board Declares That;

1. Debian is already an SPI Associated Project, according to the SPI
Framework for Associated Projects, SPI Resolution
1998-11-16.iwj.1-amended-2004-08-10.iwj.1, a copy of which can be
found at
http://www.spi-inc.org/corporate/resolutions/2004-08-10-iwj.1.

2. The Debian Constitution
(http://www.debian.org/devel/constitution), and the persons holding
the roles it defines and acting according to that Constitution, are
recognised by SPI as ultimately authoritative regarding decisions of
the Debian Project.

3. The SPI Board does not intend to monitor the Debian mailing lists.
The Board will recognise decisions, statements, and delegations made by
the Debian Project Leader, currently Anthony Towns, as made on behalf of
Debian, except to the extent this assumption is contradicted by
information to the SPI Board by the Debian Project Secretary in
accordance with paragraph 4.

4. The Board specifically asks that the Debian Project Secretary inform
the SPI Board of any Debian General Resolutions which might be relevant
to SPI, including any proposals to put spending on hold, as well as any
dispute or change regarding the identity or authority of the Debian
Project Leader.

5. The Board relies on Debian Developers and others to ensure that the
Board is made aware of Debian decisions relevant to SPI that are not
communicated to the Board in a timely manner by the Debian Project
Leader or the Debian Project Secretary; of disagreement among Debian
developers regarding the identity of the Debian Project Leader or the
Debian Project Secretary; and of disagreement among Debian developers as
to the authority held by either of those two Debian officials, but only
insofar as this authority is relevant to SPI. The Board requests that
those who notify it of decisions or disagreements in accordance with
this paragraph take reasonable efforts to look for prior notifications
to the Board on the same topic, and that the Board not be notified again
if the new notification would be substantially the same as a previous
one.

6. The Debian Constitution in 5.1(10) gives the Project Leader the
primary responsibility to decide on the proper uses of assets held in
trust by SPI for Debian purposes.
Notwithstanding this, for the avoidance of any doubt, the SPI
Board and Treasurer cannot and will not delegate their judgement
as to whether a proposed use of assets meets SPI's charitable
purposes. As recognised by the Debian Constitution in 9.2(1), SPI
must make that decision, itself ensuring SPI's funds are used
lawfully.

--- cut here ---

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Jimmy Kaplowitz wrote:
> On Fri, Mar 16, 2007 at 11:54:10AM -0700, Joshua D. Drake wrote:
>> Let Debian deal with it, and report (via the Liaison) to SPI the motion
>> etc... If the Secretary drags his/her feet, then the DDs can form a
>> quorum to recall her yes?
>
> They can actually only pass a general resolution to appoint a new
> secretary if there is a disagreement between the project leader and the
> incumbent secretary. (cf. Paragraph 4.1.7). So if the project leader is
> happy with the secretary, DDs cannot recall the project secretary
> (without first recalling the project leader and replacing him via a
> nine-week election). However, if a general resolution does get
> attempted, it is the Secretary and only the Secretary who runs votes,
> determines method of balloting, decides issues of procedure, etc.
> Therefore, if the Secretary drags his/her feet on the vote and is
> uncooperative about agreeing to a replacement Secretary, there's really
> nothing to be done. It's definitely a flaw in the system.
>

Uhmmm... yuck?

I mean... yuck. That says to me, SPI needs to deal with a significant
deficiency within Debian. I now see why.. it is such a problem though.

IMO, the SPI should respond that it is our "suggestion" that Debian
elect to change their constitution to have a representative body.

Yes I am fully aware of what I just said and we don't have to delve into
it now.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

>> Just look at the whole Dunc Tank debacle..
>
> I don't think Dunc Tank was a debacle from SPI's point of view. The
> only reason we had any serious argument about at all was this very
> point that we're arguing about again now.
>
> Obviously there was lots and lots of discussion in Debian but I don't
> see the problem really.

Oh I agree there, I was just saying I don't want that discussion
floating over here. I actually read the Dunc Tank threads (I was bored
and a little drunk one night).

Joshua D. Drake

>
> Ian.

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Fri, Mar 16, 2007 at 12:46:29PM -0700, Joshua D. Drake wrote:
> Well again, not so much opposed to the idea of them giving us
> information as much as us actually acting on it.

Well, first of all, we don't promise to do anything based on the info,
other than be glad they told us. That would be for the board to decide
in the individual instance.

> 15 DDs stood in a room and cried foul.
>
> What does that mean?
>
> 100 DDs stood in a room and cried foul.
>
> What does that mean?

Yes, the board has always needed to use judgment in interpreting
communications, and that won't change with this paragraph. We won't be
obligated to do anything; it's just to increase how likely we are to
hear of major breakdowns such as Ian was mentioning. And yes, there are
over 300 DDs (by more than a factor of 3). But, given that the final
wording has people take reasonable efforts to ensure that we haven't
already been notified, people will hopefully not notify us too
redundantly and we won't get swamped with emails any more than we
want/need to be.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Joshua D. Drake wrote:
>> As for the broader issue at hand, I very much agree with Ian that if the
>> Debian liaisons to SPI don't do their job properly and timely in
>> conveying decisions relevant to SPI, it's important for DDs to notify
>> us, both to protect Debian's decision-making integrity and for SPI's
>> own due diligence in conducting transactions. Which is why paragraph 5
>> is a useful encouragement.
>
> Well again, not so much opposed to the idea of them giving us
> information as much as us actually acting on it.
>
> 15 DDs stood in a room and cried foul.
>
> What does that mean?
>
> 100 DDs stood in a room and cried foul.
>
> What does that mean?
>
> There are over 300 DDs aren't there?
>

O.k. per Ian's other writeup, it appears that certain DDs have certain
powers. THat is interesting.

J

> Sincerely,
>
> Joshua D. Drake
>
>
>> - Jimmy Kaplowitz
>> jimmy(at)spi-inc(dot)org
>
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Joshua D. Drake writes ("Re: Draft resolution formalising Debian's Associated Project status"):
> Well again, not so much opposed to the idea of them giving us
> information as much as us actually acting on it.
>
> 15 DDs stood in a room and cried foul.
> What does that mean?

`Cried foul' is the wrong way to put it. What they would say is
something like this:

We the undersigned 12 Debian Developers have sponsored a resolution
to freeze and overturn the DPL's decision to buy a pony.

The resolution itself is here: http://lists.debian.org/....

According to the Debian constitution (http://www.debian.org/...)
section 4.2(2)(2), our opposition has immediately placed the DPL's
decision on hold. (K is Q or 5, whichever is the smaller, so our
12 sponsors are definitely at least 2K.)

So any 10 DDs are enough to put a decision on hold pending a vote.
This has rarely happened in practice.

See http://www.debian.org/devel/constitution, which is the document
that SPI has agreed to honour.

Ian.

On Fri, Mar 16, 2007 at 12:52:28PM -0700, Joshua D. Drake wrote:
> O.k. per Ian's other writeup, it appears that certain DDs have certain
> powers. THat is interesting.

Well, ones who hold certain offices, yes. But, with one exception that's
not likely to be relevant to SPI, it's not any developers in particular
who can freeze a decision, but simply a certain number of developers.
And this is immediate, without any vote needed, but possibly also
without any available and cooperative liaison to convey this news to
SPI.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

On Fri, Mar 16, 2007 at 02:24:48PM -0400, Jimmy Kaplowitz wrote:
> > (n). The SPI Board relies on Debian Developers and others to ensure
> > that if the validity of a Debian decision relevant to SPI is
> > disputed, the Board's attention is drawn to the existence of the
> > dispute, if the Board might otherwise remain unaware of it.
>
> How about this:
>
> 5. The Board relies on Debian Developers and others to ensure that the
> Board is made aware of Debian decisions relevant to SPI that are not
> communicated to the Board in a timely manner by the Debian Project
> Leader or the Debian Project Secretary; of disagreement among Debian
> developers regarding the identity of the Debian Project Leader or the
> Debian Project Secretary; and of disagreement among Debian developers as
> to the authority held by either of those two Debian officials, but only
> insofar as this authority is relevant to SPI. The Board requests that
> those who notify it of decisions or disagreements in accordance with
> this paragraph take reasonable efforts to look for prior notifications
> to the Board on the same topic, and that the Board not be notified again
> if the new notification would be substantially the same as a previous
> one.

Just looking at the sheer length, I think you just presented a great case
for the opponents of legalese. Sorry :)

Does everything really have to be spelled out like that? Surely the board
can exercise some common sense in preventing people from making duplicate
and/or pointless queries, and not have to resort to this kind of verbosity?

I know it doesn't seem like this to you now, but a few years from now, this
might actually sound like SPI showing a priori contempt for people trying to
notify it about the aforementioned problems...

Ian's version seemed just fine to me, except that it could have used the
words 'according to the Debian Constitution' somewhere, just to make sure
that we're talking about real disputes and not any random chatter.

--
2. That which causes joy or happiness.

On Fri, Mar 16, 2007 at 10:47:22PM +0100, Josip Rodin wrote:
> Does everything really have to be spelled out like that? Surely the board
> can exercise some common sense in preventing people from making duplicate
> and/or pointless queries, and not have to resort to this kind of verbosity?

It's not a matter of the board preventing people from contacting us,
since we're not going to be going around engaging in censorship. And in
any case, this was about informing us know of a bad situation, not about
making any sort of query. The tricky part was how to word the request we
were making. Ian's wording requested that the person guess as to whether
the board was likely to find out about the situation, which could lead
to radically different judgments depending on how involved the person is
in the issue in question. My wording (which Ian was fine with) simply
asked them to do a quick objective look out there to see if it looks
like we've been notified. Verbosity can actually lead to better results.

It also might not have seemed so verbose if I had broken it up into two
paragraphs.

> I know it doesn't seem like this to you now, but a few years from now, this
> might actually sound like SPI showing a priori contempt for people trying to
> notify it about the aforementioned problems...

Why would they think that given that it's in the same paragraph as an
explicit request to notify us for those problems?

> Ian's version seemed just fine to me, except that it could have used the
> words 'according to the Debian Constitution' somewhere, just to make sure
> that we're talking about real disputes and not any random chatter.

It was substantively different in the regard I mentioned above, but also
in that it would have us depend on DDs and others to let us know about
disagreements on decisions themselves, which is none of SPI's business,
rather than disagreements on the authority of the decisionmakers to make
a decision relevant to SPI, which is most definitely our business.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

On Fri, Mar 16, 2007 at 06:01:48PM -0400, Jimmy Kaplowitz wrote:
> Verbosity can actually lead to better results.

...unless you later find out that you missed a spot... :)

> > I know it doesn't seem like this to you now, but a few years from now,
> > this might actually sound like SPI showing a priori contempt for people
> > trying to notify it about the aforementioned problems...
>
> Why would they think that given that it's in the same paragraph as an
> explicit request to notify us for those problems?

Yeh, please notify us, but don't do <insert 200 words here>.
That's not really encouraging. :)

> > Ian's version seemed just fine to me, except that it could have used the
> > words 'according to the Debian Constitution' somewhere, just to make sure
> > that we're talking about real disputes and not any random chatter.
>
> It was substantively different in the regard I mentioned above, but also
> in that it would have us depend on DDs and others to let us know about
> disagreements on decisions themselves, which is none of SPI's business,
> rather than disagreements on the authority of the decisionmakers to make
> a decision relevant to SPI, which is most definitely our business.

Like I said, it should just restrict itself to constitutionally implemented
disputes. (s/could/should/ in my previous sentence) Any such
constitutionally implemented dispute would necessarily impair the authority
of our liaisons at SPI, so it would be relevant.

--
2. That which causes joy or happiness.

> Like I said, it should just restrict itself to constitutionally implemented
> disputes. (s/could/should/ in my previous sentence) Any such
> constitutionally implemented dispute would necessarily impair the authority
> of our liaisons at SPI, so it would be relevant.
>

Isn't this all moot now? I believe the board already passed the resolution.

J

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Fri, Mar 16, 2007 at 02:09:49PM -0400, Theodore Tso wrote:
> The only thing which the SPI should care about with respect to the
> authority held by the DPL and the Secretary is their authority with
> respect to the requests made to the SPI. And these authorities is
> somethign which can and should be very clearly enumerated.

I agree. Paragraph 5 of the final draft which the board approved today
only referred to their authority insofar as it is relevant to SPI, not
every aspect of their authority. Read literally, paragraph 4's final
version unintentionally applied the relevance restriction only to
notification about GRs, and not to disputes or changes regarding the
DPL's authority, but given context and common sense, I'd expect that
people will be reasonable in interpreting and applying that paragraph.

If it actually becomes a problem where the Debian Secretary feels
compelled to tell SPI about irrelevant changes in the DPL position, we
can fix the wording to be precisely correct at that time. I, for one,
think the imprecision will have little enough practical effect that it's
not worth worrying about or spending time to correct unless we find that
it ends up mattering. If you agree, let's end this thread.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

P.S. - "SPI", not "the SPI".

On Fri, Mar 16, 2007 at 09:16:12PM -0400, Jimmy Kaplowitz wrote:
> Read literally, paragraph 4's final version unintentionally applied the
> relevance restriction only to notification about GRs, and not to disputes
> or changes regarding the DPL's authority, but given context and common
> sense, I'd expect that people will be reasonable in interpreting and
> applying that paragraph.

See, that's exactly why I said "...unless you later find out that you missed
a spot... :)" earlier. But anyway, I've made that point twice now, I'll let
it rest. Let's end the thread.

--
2. That which causes joy or happiness.