Draft resolution formalising Debian's Associated Project status

[MJ Ray]

Theodore Ts'o <tytso at mit.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/