Re: proposed SPI resolution

Hi all. FFmpeg has applied to become an SPI Associated project. Comments
and questions are welcome.

I support and am sponsoring this application because:

* FFmpeg is a genuine Free Software community project:

FFmpeg is released under the GPL or LGPL licenses depending on
the choice of configuration options.

* FFmpeg has an established development community and history of software
releases.

The initial release of FFmpeg was in December 2000 and the project
continues to be actively developed.

* FFmpeg is used by a broad audience:

FFmpeg is widely used on Linux, Microsoft Windows and many other operating
systems both as a standalone tool and as part of other applications.

The resolution below is proposed to be submitted to the June 14 board
meeting:

SPI resolution 2012-05-25.rtb.1

WHEREAS

1. FFmpeg is a substantial and significant Free Software project.

2. The FFmpeg developers would like SPI's support and assistance,
including taking Donations, Holding Funds and legal assistance.

THE SPI BOARD RESOLVES THAT

3. FFmpeg is formally invited to become 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/2004-08-10.iwj.1/

4. Stefano Sabatini is recognised by SPI as the authoritative decision
maker and SPI liaison for FFmpeg. Successors will be appointed
following a concensus on the ffmpeg-devel(at)ffmpeg(dot)org mailing list. If
a concensus cannot be achieved an election for the SPI liaison will be
held among members of the ffmpeg-devel(at)ffmpeg(dot)org mailing list.

5. This invitation will lapse, if not accepted, 60 days after it is
approved by the SPI Board.

Full text of application for SPI associated project status:

--- Begin Application ---

Name and details of the project
===============================

The FFmpeg project was founded in 2000 by Fabrice Bellard, who is
also the trademark holder.

Website: http://www.ffmpeg.org/

FFmpeg aims to provide a complete, cross-platform solution to
multimedia processing including decoding, encoding, demuxing, muxing,
streaming, filtering, metadata processing, etc.

It comprises both a commandline toolset (ffmpeg, ffplay, ffprobe,
ffserver) and several libraries. For more info, check:
http://ffmpeg.org/about.html

FFmpeg currently supports a huge number of components, notably a large
number of codecs (more or less known), some of which have been reverse
engineered by FFmpeg developers. Furthermore some formats have been
designed and implemented within FFmpeg, in particular the NUT
container, and the FFV1 and Snow codecs.

FFmpeg aims to support formats and features natively, for example when
there is no active free software project providing support in a given
area, but relies on external libraries (e.g. libmp3lame, libx264) when
it makes sense.

FFmpeg is free software licensed under the LGPL or GPL depending on
the choice of configuration options.

FFmpeg is used by a large number of multimedia FLOSS projects
(e.g. MPlayer, VLC, Chromium, Blender etc., see
http://ffmpeg.org/projects.html for a more comprehensive list), and is
used as backend in a large number of multimedia website conversion
services (possibly including Google Video, Facebook and YouTube), and
is shipped by many Linux distros, for example Fedora and Centos. See:
http://distrowatch.com/search.php?pkg=ffmpeg&pkgver=#pkgsearch
for an indepth survey.

The Windows platform is supported through MinGW, and daily Windows
builds are provided by third parties like for example:
http://ffmpeg.zeranoe.com/builds/

At the beginning of 2011 a group of developers created a fork which
was named Libav (for the fine details read the March 15, 2011 news
entry on ffmpeg.org). Most Libav changes are merged regularly into
FFmpeg.

Which SPI services will be needed
=================================

We request the following services to SPI:

- Accepting Donations and Holding Funds on behalf of FFmpeg
- Legal Assistance

In case of need we reserve the possibility to ask for other services.

Who is going to be the liaison to SPI, and the process for selecting/electing replacements
==========================================================================================

I, Stefano Sabatini, am going to assume the role of liaison while this
application is processed.

In case of application approval, the liaison will be chosen over
agreement on the public ffmpeg-devel mailing list. In case a consensus
can't be reached we'll establish a vote for electing the liaison, and
we will delay expense/refund approvals until we get a proper consensus
on the liaison choice or election.

The liaison mandate will last a fixed period, orientatively one year,
at the end of which we will run a new selection process. The liaison
role change will be promptly notified to SPI.

Every refund request will be posted to the project public development
mailing list (ffmpeg-devel(at)ffmpeg(dot)org) and can be discussed by the
developers and other interested parties, it's also possible for the
project maintainer (currently Michael Niedermayer) to veto a request
before 7 days have passed since the liaison approval.

Every refund request sent by the liaison will have a link to the
public discussion, so SPI can check that the issue was public 7 days
ago at least and it has not received a veto, or it has been explicitly
approved so it can be considered valid.

--- End Application ---

Thanks,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world

Robert Brockway writes ("FFmpeg as SPI associated project"):
...
> 4. Stefano Sabatini is recognised by SPI as the authoritative decision
> maker and SPI liaison for FFmpeg. Successors will be appointed
> following a concensus on the ffmpeg-devel(at)ffmpeg(dot)org mailing list. If
> a concensus cannot be achieved an election for the SPI liaison will be
> held among members of the ffmpeg-devel(at)ffmpeg(dot)org mailing list.

I don't think this is correct.

I went to look at the ffpmeg-devel list
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-May/thread.html
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-May/124311.html
and Stefano is not the project's autocrat, which is what
"authoritative decision maker" would mean to me.

(NB I'm not accusing Stefano of some kind of power grab, or anything.
But we should get this right and one of the reasons for writing this
stuff down now is so that we have something to refer to in the future
if there should be any kind of argument.)

Given what I understand to be the internal processes in FFmpeg I would
prefer to see something like this:

Stefano Sabatini is recognised by SPI as the current liason for
FFmpeg. SPI expects him to inform us of decisions relating to SPI
made by the FFmpeg project, and we will honour his requests in
accordance with the Framework for Associated Projects.

However FFmpeg does not currently have a formal governance
structure. Therefore in case of significant dispute, SPI will
follow what appears to the SPI Board to be the rough consensus
view of the FFmpeg project committers.

The effect would be the same for routine transactions, but it makes it
clear that if there is some kind of dispute or split within FFmpeg,
the SPI Board will ultimately make the decision about what appears to
be the rough consensus view of the FFmpeg project.

That avoids the FFmpeg project having to invent a formal governance
structure just for its dealings with SPI. I would rather not force
associated projects down that path unless they want it for themselves.
Rather I would like SPI to be able to reuse whatever understandings
about governance already exist - even if that means that occasionally
the SPI Board might end up having to make a tricky decision rather
than just following the letter of some rules.

The exact phrase "rough consensus view of the FFmpeg project
committers" is the key point here and seems to me to be the closest
thing to a governing body in FFmpeg. If I am mistaken then please
correct me.

Stefano, does this seem right to you ?

Ian.

On Thu, 24 May 2012, Ian Jackson wrote:

> Robert Brockway writes ("FFmpeg as SPI associated project"):
> ...
>> 4. Stefano Sabatini is recognised by SPI as the authoritative decision
>> maker and SPI liaison for FFmpeg. Successors will be appointed
>> following a concensus on the ffmpeg-devel(at)ffmpeg(dot)org mailing list. If
>> a concensus cannot be achieved an election for the SPI liaison will be
>> held among members of the ffmpeg-devel(at)ffmpeg(dot)org mailing list.
>
> I don't think this is correct.
>
> I went to look at the ffpmeg-devel list
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-May/thread.html
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-May/124311.html
> and Stefano is not the project's autocrat, which is what
> "authoritative decision maker" would mean to me.

Hi Ian. Since the resolution is only binding on SPI I read it with that
limitation in mind (the wording comes from the template). Ie we aren't
asserting that Stefano is an authoritative decision maker in an absolute
sense but that he is the authoritative decision maker as far as SPI is
concerned. Having said that, IANAL.

Associated projects have a variety of internal governance structures but
present a well defined interface to SPI.

I'm not sure if you read the entire application but FFmpeg specify that
they will have a 7 day review period of any reimbursement request on the
ffmpeg-devel(at)ffmpeg(dot)org list. By the time SPI receives the request it has
passed through the 7 day review period and has not been vetoed by the
project maintainer (currently Michael Niedermayer).

[SNIP suggestion for revised wording for brevity]

Resolution 2004-08-10.iwj.1 already grants SPI the ability to act if
project governance has broken down:

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

I realise you know this resolution well, having originally submitted it.

> That avoids the FFmpeg project having to invent a formal governance
> structure just for its dealings with SPI. I would rather not force
> associated projects down that path unless they want it for themselves.

Well I think FFmpeg set up the structure that SPI requires of all
associated projects, a post of "project liaison" and a process to
determine successors to the current project liaison.

> Stefano, does this seem right to you ?

I still think the existing wording is correct but I have no problem
revising the proposal if necessary. Let's see what Stefano and the rest
of the community say on this. There is plenty of time before the next
board meeting for a discussion.

Cheers,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world

In data Friday 2012-05-25 08:29:11 +1000, Robert Brockway ha scritto:
> On Thu, 24 May 2012, Ian Jackson wrote:
>
> >Robert Brockway writes ("FFmpeg as SPI associated project"):
> >...
> >>4. Stefano Sabatini is recognised by SPI as the authoritative decision
> >> maker and SPI liaison for FFmpeg. Successors will be appointed
> >> following a concensus on the ffmpeg-devel(at)ffmpeg(dot)org mailing list. If
> >> a concensus cannot be achieved an election for the SPI liaison will be
> >> held among members of the ffmpeg-devel(at)ffmpeg(dot)org mailing list.
> >
> >I don't think this is correct.
> >
> >I went to look at the ffpmeg-devel list
> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-May/thread.html
> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-May/124311.html
> >and Stefano is not the project's autocrat, which is what
> >"authoritative decision maker" would mean to me.

Yes I'm not an autocrat ;-). That said from my reading of the SPI
associated project HOWTO i see no mention that the liaison must
coincide with the project leader/maintainer/BDFL/whatever.

Some reasons for which we opted to have this power "division": first
and foremost, avoid to charge the current project maintainer with more
administrative burden, limit the power/harm/abuse of a single decision
maker with regards to funds management (at the cost of a potential
slow down of the decision process), and at the same time give more
"legitimation" to the approved decision since it has to be approved by
at least two persons.

(Currently we devised a mechanism where the liaison approves a
request, and the project maintainer can veto it during a one week
timeframe).

Note also that still nothing is cast in stone, so we can still make
changes in case there is the need to comply with SPI rules.

[...]
> >That avoids the FFmpeg project having to invent a formal governance
> >structure just for its dealings with SPI. I would rather not force
> >associated projects down that path unless they want it for themselves.
>
> Well I think FFmpeg set up the structure that SPI requires of all
> associated projects, a post of "project liaison" and a process to
> determine successors to the current project liaison.
>
> >Stefano, does this seem right to you ?

Yes.

> I still think the existing wording is correct but I have no problem
> revising the proposal if necessary. Let's see what Stefano and the
> rest of the community say on this. There is plenty of time before
> the next board meeting for a discussion.

Cheers.

Stefano Sabatini writes ("Re: FFmpeg as SPI associated project"):
> In data Friday 2012-05-25 08:29:11 +1000, Robert Brockway ha scritto:
> Yes I'm not an autocrat ;-). That said from my reading of the SPI
> associated project HOWTO i see no mention that the liaison must
> coincide with the project leader/maintainer/BDFL/whatever.

Yes, that's fine.

My problem is that the draft SPI resolution says:

4. Stefano Sabatini is recognised by SPI as the authoritative decision
maker and SPI liaison for FFmpeg. [...]

"Authoritative decisionmaker" is a mealy-mouthed way of saying
"autocrat". I should know: I wrote that wording for the benefit of a
project which was in fact run as an autocracy. And if you are in any
doubt, please do consult a dictionary. "The authoritative
decisionmaker for FFmpeg" is the person whose decisions about FFmpeg
are in themselves authoritative - ie, the autocrat. Which FFmpeg
doesn't have.

This part of these project acceptance resolutions is not some kind of
template which needs to just have the project name and the liason name
plugged into it. This clause is supposed to state what SPI's
understanding is of FFmpeg's governance structure. It is obviously
important for SPI to know what FFmpeg's governance structure is so
that SPI can honour it. (And that needs to be sorted out in advance
of any dispute arising, so just because things are all rosy now
doesn't mean it's not important.) The purpose of putting this clause
in these accession resolutions is to make a clear public statement,
for review both by SPI and the proposed project, of what the common
understanding is.

So as I say since FFmpeg is not an autocracy, it is not correct to say
that "Stefano Sabatini is the authoritative decisionmaker for FFmpeg".
Rather, that is a false statement. Therefore "SPI recognises that
Stefano is the authoritative decisionmaker" is also inappropriate.
SPI should not "recognise that {false statement}".

Hence my proposed alternative wording:

Stefano Sabatini is recognised by SPI as the current liason for
FFmpeg. SPI expects him to inform us of decisions relating to SPI
made by the FFmpeg project, and we will honour his requests in
accordance with the Framework for Associated Projects.

However FFmpeg does not currently have a formal governance
structure. Therefore in case of significant dispute, SPI will
follow what appears to the SPI Board to be the rough consensus
view of the FFmpeg project committers.

Is this a proper understanding and reflection of FFmpeg's governance
structure ?

> Some reasons for which we opted to have this power "division": first
> and foremost, avoid to charge the current project maintainer with more
> administrative burden, limit the power/harm/abuse of a single decision
> maker with regards to funds management (at the cost of a potential
> slow down of the decision process), and at the same time give more
> "legitimation" to the approved decision since it has to be approved by
> at least two persons.

That's entirely for FFmpeg to decide.

> (Currently we devised a mechanism where the liaison approves a
> request, and the project maintainer can veto it during a one week
> timeframe).

That's entirely for FFmpeg to decide.

But to make this workable, we need to have a process from SPI's point
of view that relies on trusting the liason for day-to-day stuff.

That is, the point of having the liason is not that the liason's word
is definitive with respect to what SPI does. The point is that the
liason is responsible for communicating decisions (however made) to
SPI. So whenever some decision (eg a spending decision) is made by
FFmpeg (collectively, in whatever way is established for and by
FFmpeg), the liason communicates that to SPI by saying `we have
decided that we would like to spend $X on Y' and the SPI Treasurer
writes a cheque or whatever.

If the liason breaches FFmpeg's processes (for example by sending
unilateral requests to SPI for money to be spent, or whatever) they
would, in effect, be lying to SPI.

We hope that if that should happen, someone else from FFmpeg would
notice and bring it to SPI's attention. Then SPI would consult the
accession resolution to see how to resolve the dispute. So the
accession resolution needs to say what to do.

In this case Robert's wording would imply that the dispute would be
resolved by doing whatever Stefano Sabatini says. (I know Robert
doesn't seem to think that, but I think that's what `authoritative
decisionmaker' means. Even Robert should see that we need a wording
which is not subject to disputes about its meaning.)

In this case my wording would mean someone from SPI would have to
figure out who the current FFmpeg committers were, and ask them.

Would that be correct ? If so, then we should IMO have my wording or
something like it. If not then we need something different.

Ian.

Ian Jackson writes ("Re: FFmpeg as SPI associated project"):
> Stefano Sabatini writes ("Re: FFmpeg as SPI associated project"):
> > In data Friday 2012-05-25 08:29:11 +1000, Robert Brockway ha scritto:
> > Yes I'm not an autocrat ;-). That said from my reading of the SPI
> > associated project HOWTO i see no mention that the liaison must
> > coincide with the project leader/maintainer/BDFL/whatever.
>
> Yes, that's fine.
>
> My problem is that the draft SPI resolution says:
>
> 4. Stefano Sabatini is recognised by SPI as the authoritative decision
> maker and SPI liaison for FFmpeg. [...]
>
> "Authoritative decisionmaker" is a mealy-mouthed way of saying
> "autocrat". I should know: I wrote that wording for the benefit of a
> project which was in fact run as an autocracy. And if you are in any
> doubt, please do consult a dictionary. "The authoritative
> decisionmaker for FFmpeg" is the person whose decisions about FFmpeg
> are in themselves authoritative - ie, the autocrat. Which FFmpeg
> doesn't have.

I have just seen, following your reference to the
`associated-project-howto', that that document contains the wording
`authoritative decisionmaker' which I am objecting to.

Who wrote the associated-project-howto and how can we get this fixed ?

At the moment it says:

4. [Liaison] is recognised by SPI as the authoritative decision maker
and SPI liaison for [project]. Successors will be appointed
[describe method of selection or election].

IMO it should say:

4. [Liason] will be the initial liason to SPI from [project]
and is responsible in the first instance for communicating the
wishes of [project] to SPI.

[SPI understands that decisions in [project] are made according
to [process].]
[or something similar]

In case of dispute SPI will honour those decisions in accordance
with the SPI Framework.

or something like that.

Ian.

SPI resolution 2012-05-31.ba.1

WHEREAS

1. liaison is written with three vowels in a row.

2. liaison is mispelled near-systematically on the SPI mailing lists by non French speakers.

3. this is bound to irritate the small number of French speakers which are subscribed
to the SPI mailing lists (which, by the way, are wondering how English people
pronounce it, assuming they can) even when they have an English-looking first name.

4. there are less Latin speakers than French speakers subscriber to SPI mailing lists.

THE SPI BOARD RESOLVES THAT

1. the word liaison will be replaced by ligatio in all SPI documents.

2. the non-words liason, laison and laiason will also be replaced by ligatio in
all SPI documents for consistency.

3. A small number of mispelling of ligatio will be encouraged to avoid an
entropy imbalance.

Respectfully submitted,
Bill "no middle name" Allombert.

> THE SPI BOARD RESOLVES THAT
>
> 1. the word liaison will be replaced by ligatio in all SPI documents.
>
> 2. the non-words liason, laison and laiason will also be replaced by ligatio in
> all SPI documents for consistency.
>
> 3. A small number of mispelling of ligatio will be encouraged to avoid an
> entropy imbalance.

Hah!

Seriously, if we wanted to replace it, any of the following words would
work:

- delegate
- representative
- manager

--Josh Berkus

Hi Bill,

On Thu, May 31, 2012 at 02:43:02PM +0200, Bill Allombert wrote:
> SPI resolution 2012-05-31.ba.1
>
> WHEREAS
>
> 1. liaison is written with three vowels in a row.
>
> 2. liaison is mispelled near-systematically on the SPI mailing lists by non French speakers.

s/mispelled/misspelled/, s/non French/non-French/, (more arguable) s/near-systematically/nearly systematically/

> 3. this is bound to irritate the small number of French speakers which are subscribed
> to the SPI mailing lists (which, by the way, are wondering how English people
s/which/who/
> pronounce it, assuming they can) even when they have an English-looking first name.

Usually the same way as in French (which I also speak), except probably with
the nasal French "on" replaced with either the Spanish "ón" or the English "on"
depending on the speaker.

> 4. there are less Latin speakers than French speakers subscriber to SPI
> mailing lists.

s/less/fewer/; s/subscriber/subscribed/

>
> THE SPI BOARD RESOLVES THAT
>
> 1. the word liaison will be replaced by ligatio in all SPI documents.
>
> 2. the non-words liason, laison and laiason will also be replaced by ligatio
> in all SPI documents for consistency.

Given that your proposal would be an SPI document, that would be interestingly
recursive.

> 3. A small number of mispelling of ligatio will be encouraged to avoid an
> entropy imbalance.

s/mispelling/misspellings/

> Respectfully submitted, Bill "no middle name" Allombert.

Merci pour l'avis! :-)

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

Il 31/05/2012 14:43, Bill Allombert ha scritto:
> THE SPI BOARD RESOLVES THAT
>
> 1. the word liaison will be replaced by ligatio in all SPI documents.

I don't think that word is appropriate: "ligatio" is more the act of
binding, instead of the bound person. A much more better word is
probably "legatus", that actually means "ambassador" (although for a
slightly different reason: it would mean that the
legatus/liaison/whatever is bound to the project he's part of, not that
he serves as binding between the project and SPI).

BTW, I would oppose the use of a Latin word, because I really couldn't
stand with hearing it pronounced from English-speaking people (probably
I would write down that pronounciation as "leghedas", quite different
from "legatus"). :-)

Gio.
--
Giovanni Mascellani <mascellani(at)poisson(dot)phc(dot)unipi(dot)it>
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g(dot)mascellani(at)jabber(dot)org / giovanni(at)elabor(dot)homelinux(dot)org

On Thu, 31 May 2012, Ian Jackson wrote:

> I have just seen, following your reference to the
> `associated-project-howto', that that document contains the wording
> `authoritative decisionmaker' which I am objecting to.

Hi Ian. If you look at the resolutions (see link below) you will see the
same wording used in virtually every resolution accepting a project over
the last few years.

http://www.spi-inc.org/corporate/resolutions/

While I don't object to your objection (really) I did want to point out
that this phrase has been in use in resolutions for a long time so I was
surprised to see the objection appear now.

If the board doesn't object, I'm happy to refer this to SPI counsel for
advice. This will happen in parallel to the current proposal of course.

> Who wrote the associated-project-howto and how can we get this fixed ?

I did a major clean up on the associated project howto in late 2011. I
added content, reorganised it and split it into three documents.

The original version of the document can be found here:

http://www.spi-inc.org/projects/old-associated-project-howto/

I understand that Josh Berkus wrote the original version. My suspicion is
that the 'proposal template' in question predates this.

Cheers,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world

Robert Brockway writes ("Re: FFmpeg as SPI associated project"):
> While I don't object to your objection (really) I did want to point out
> that this phrase has been in use in resolutions for a long time so I was
> surprised to see the objection appear now.

I'm sorry that I haven't spotted that earlier!

> I understand that Josh Berkus wrote the original version. My suspicion is
> that the 'proposal template' in question predates this.

Quite probably.

Ian.

On Fri, Jun 01, 2012 at 11:20:11PM +1000, Robert Brockway wrote:
> While I don't object to your objection (really) I did want to point
> out that this phrase has been in use in resolutions for a long time
> so I was surprised to see the objection appear now.

I think very few SPI associated projects have the ultimate decisionmaking
authority in the hands of the rough consensus of a mailing list. Most have
something more formal than that, which might explain why it's an uncommon
issue. Or, yes, unthinking reuse of previous templates is another possible
explanation. :-)

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

Josh Berkus writes ("Re: proposed SPI resolution"):
> Seriously, if we wanted to replace it, any of the following words would
> work:
>
> - delegate
> - representative
> - manager

"Representative" seems the closest. The job is to represent the
associated project to SPI.

And, to head off an obvious objection, representation naturally
always also includes helping with the information flow in the other
direction.

Ian.

In data Thursday 2012-05-31 13:33:34 +0100, Ian Jackson ha scritto:
> Stefano Sabatini writes ("Re: FFmpeg as SPI associated project"):
[...]
> This part of these project acceptance resolutions is not some kind of
> template which needs to just have the project name and the liason name
> plugged into it. This clause is supposed to state what SPI's
> understanding is of FFmpeg's governance structure. It is obviously
> important for SPI to know what FFmpeg's governance structure is so
> that SPI can honour it. (And that needs to be sorted out in advance
> of any dispute arising, so just because things are all rosy now
> doesn't mean it's not important.) The purpose of putting this clause
> in these accession resolutions is to make a clear public statement,
> for review both by SPI and the proposed project, of what the common
> understanding is.
>
> So as I say since FFmpeg is not an autocracy, it is not correct to say
> that "Stefano Sabatini is the authoritative decisionmaker for FFmpeg".
> Rather, that is a false statement. Therefore "SPI recognises that
> Stefano is the authoritative decisionmaker" is also inappropriate.
> SPI should not "recognise that {false statement}".
>
> Hence my proposed alternative wording:
>
> Stefano Sabatini is recognised by SPI as the current liason for
> FFmpeg. SPI expects him to inform us of decisions relating to SPI
> made by the FFmpeg project, and we will honour his requests in
> accordance with the Framework for Associated Projects.
>
> However FFmpeg does not currently have a formal governance
> structure. Therefore in case of significant dispute, SPI will
> follow what appears to the SPI Board to be the rough consensus
> view of the FFmpeg project committers.
>
> Is this a proper understanding and reflection of FFmpeg's governance
> structure ?

Yes, seems reasonable. "In case of significant dispute" I suppose in
case there is no agreement between project maintainer and liaison but
one of them want to force a request (unlikely but not inconceivable),
in this case SPI should simply not validate the request.

Also the term "committers" is not really valid in case of FFmpeg given
our recent history, I believe the term "direct contributors" is more
suited to the current status of the project.

[...]
> That's entirely for FFmpeg to decide.
>
> But to make this workable, we need to have a process from SPI's point
> of view that relies on trusting the liason for day-to-day stuff.
>
> That is, the point of having the liason is not that the liason's word
> is definitive with respect to what SPI does. The point is that the
> liason is responsible for communicating decisions (however made) to
> SPI. So whenever some decision (eg a spending decision) is made by
> FFmpeg (collectively, in whatever way is established for and by
> FFmpeg), the liason communicates that to SPI by saying `we have
> decided that we would like to spend $X on Y' and the SPI Treasurer
> writes a cheque or whatever.
>
> If the liason breaches FFmpeg's processes (for example by sending
> unilateral requests to SPI for money to be spent, or whatever) they
> would, in effect, be lying to SPI.

In the application we provided a mechanism which allows to verify if a
fund request has been approved:

a fund request is discussed in the public mailing list, and approved
by the liaison; it is also approved by the project maintainer, or 7
days pass with no explicit disapproval

in this case the liaison will send a mail with a link to the public
mailing list with the request approval. The SPI treasurer can directly
verify that the request was approved.

> We hope that if that should happen, someone else from FFmpeg would
> notice and bring it to SPI's attention. Then SPI would consult the
> accession resolution to see how to resolve the dispute. So the
> accession resolution needs to say what to do.
>
> In this case Robert's wording would imply that the dispute would be
> resolved by doing whatever Stefano Sabatini says. (I know Robert
> doesn't seem to think that, but I think that's what `authoritative
> decisionmaker' means. Even Robert should see that we need a wording
> which is not subject to disputes about its meaning.)
>
> In this case my wording would mean someone from SPI would have to
> figure out who the current FFmpeg committers were, and ask them.
>
> Would that be correct ? If so, then we should IMO have my wording or
> something like it. If not then we need something different.

OK, so we need to understand what we exactly need to do in order to
comply with the SPI terms, and in particular how we need to advance in
terms of "formal governance structure" so SPI knows how to deal in
case a "significant dispute" arises.

Best.

On Fri, 1 Jun 2012, Jimmy Kaplowitz wrote:

> I think very few SPI associated projects have the ultimate decisionmaking
> authority in the hands of the rough consensus of a mailing list. Most have
> something more formal than that, which might explain why it's an uncommon
> issue. Or, yes, unthinking reuse of previous templates is another possible
> explanation. :-)

I actually expected the reference to the mailing list in the resolution to
be raised as a concern if anything was going to be.

I thought about this for a while and reviewed existing resolutions before
posting resolution 2012-05-25.rtb.1 . I noted that resolution
2011-08-10.bg.2 (Arch Linux as associated project) places the ability to
appoint the project liaison in the hands of "a simple majority of existing
Arch Linux developers" if a sitting liaison does not appoint their own
successor.

I concluded that using a mailing list for this purpose is not such a large
departure from existing practice.

As noted in an earlier post, I was also aware that resolution
2004-08-10.iwj.1 (Associated Project Framework) allows SPI to act if a
project's internal organization or procedures are unclear or disputed.

Taking all of this in to account, I concluded I was happy to post the
proposal.

Cheers,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world