Draft of new associated-project-howto for review

Hi all. I personally feel that the associated-project-howto could be made
clearer. I also read a few threads on various forums where some people
had expressed confusion over certain aspects of how SPI works, even after
reading the associated-project-howto.

I've written a new version which I'm submitting here for review. It can
be found here:

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

The changes I've made include:

* Rewritting the document to be in the 3rd person
* Rewritting certain sections to be clearer
* Putting information on services offered at the top[1]
* Rearranging large sections to be consistent with the new structure
* Adding more headers to stop it easier to find a relevant section.

[1] Projects considering applying for associated project status will want
to answer 'why' before they answer 'how'.

I stress this is solely my work and is not endorsed by the SPI board. I
hope that this (or something close to it) meets with the approval of the
contributing members and the board.

Cheers,

Rob

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

Robert Brockway <robert(at)spi-inc(dot)org> wrote:

> Hi all. I personally feel that the associated-project-howto could be
> made clearer. I also read a few threads on various forums where some
> people had expressed confusion over certain aspects of how SPI works,
> even after reading the associated-project-howto.
>
> I've written a new version which I'm submitting here for review. It can
> be found here:
>
> http://www.spi-inc.org/drafts/associated-project-howto/
>
> The changes I've made include:
>
> * Rewritting the document to be in the 3rd person
> * Rewritting certain sections to be clearer
> * Putting information on services offered at the top[1]
> * Rearranging large sections to be consistent with the new structure
> * Adding more headers to stop it easier to find a relevant section.
>
> [1] Projects considering applying for associated project status will
> want to answer 'why' before they answer 'how'.
>
> I stress this is solely my work and is not endorsed by the SPI board. I
> hope that this (or something close to it) meets with the approval of the
> contributing members and the board.

I agree that the draft is an improvement, thanks for working on this.

1) There seems to be a word missing ("be"?):

| Refunds for legitimate project expenses will made from
| funds earmarked for an associated project with the consent
| of the project liaison.

2) It's in the original as well, but I'm a bit puzzled by the "major" in:

| All major contributors to the project are eligible for SPI contributing membership,

According to http://www.spi-inc.org/membership/guidelines/
being active in an associated project should suffice.

3) Maybe the sentence:

| In the future, there will be an online reporting interface
| which will allow the liaison to check balances at any time.

should be dropped, or is anyone actually working on this?

4) I think it would be worth mentioning that SPI has partner
organizations that can collect tax-deducible donations outside
the US. At least for Privoxy this was an important factor,
even though the process should probably be streamlined
and documented more clearly.

Fabian

A few comments based on my recent experience with Drizzle becoming and
Associated project:

In general I think the old material was fairly good already. I always
felt SPI was easy to approach and it was clear what to expect.

But things can always be improved so here are a few ideas:

1) Enumerating SPI services up front is great - exactly what one wants
to know first. ("Why" before "How"). Please add registering and
holding domain names to intangible assets, I think it's a very
important service. Many projects essentially are the .org website that
they have.

2) A thing that is not mentioned at all is liability protection of
individual developers.

As an example, SFC says this:
When a project joins Conservancy, it formally becomes part of the
Conservancy. (The project is thus somewhat analogous to a division of
a company or a department in a large agency.) As such, project leaders
benefit from some amount of protection from personal liability for
their work on the project.
(http://sfconservancy.org/members/services/)

Possibly there's some similar benefit in joining the SPI too, for
instance money is not transferred through anyones individual bank
account and SPI also signs the contracts. On the other hand I don't
see that SPI is the kind of organisation that takes responsibility for
the actual code being produces, e.g. SPI isn't liable for things like
copyright or patent infringement lawsuits.

Whatever the SPI's position on that is, it could be good to clarify.

3) Liaison

The Howto effectively recommends or at least suggests a simple model
where a Liaison appoints himself and then his successors.

When we joined, Josh Berkus recommended we adopt a model which also
includes an appointing council, yet is similarly lightweight and self
appointing in spirit:

4. Henrik Ingo is recognised by SPI as the authoritative decision maker and
SPI liaison for Drizzle. Successors will be appointed by simple majority
vote of the Drizzle SPI Council. The Drizzle SPI Council will initially
consist of Brian Aker, Lee Bieber, Stewart Smith, Monty Taylor, and Henrik
Ingo, and may fill vacancies on the Council by majority vote of the
remaining Council members on resignation or absence of any Council member.

This model has many advantages over a single self appointed person
having all control, but doesn't really add any overhead in normal
circumstances. I'd recommend to template this format and suggest it as
an alternative (or the primary?) model of appointing a liaison.

Also, please link to the pages on postgresql.org and debian.org that
outline how they elect their liaison. If a project wants to learn
about more elaborate governance models, those are great examples to
look at.

henrik

On Fri, Sep 9, 2011 at 7:16 PM, Robert Brockway <robert(at)spi-inc(dot)org> wrote:
> Hi all.  I personally feel that the associated-project-howto could be made
> clearer.  I also read a few threads on various forums where some people had
> expressed confusion over certain aspects of how SPI works, even after
> reading the associated-project-howto.
>
> I've written a new version which I'm submitting here for review.  It can be
> found here:
>
> http://www.spi-inc.org/drafts/associated-project-howto/
>
> The changes I've made include:
>
> * Rewritting the document to be in the 3rd person
> * Rewritting certain sections to be clearer
> * Putting information on services offered at the top[1]
> * Rearranging large sections to be consistent with the new structure
> * Adding more headers to stop it easier to find a relevant section.
>
> [1] Projects considering applying for associated project status will want to
> answer 'why' before they answer 'how'.
>
> I stress this is solely my work and is not endorsed by the SPI board.  I
> hope that this (or something close to it) meets with the approval of the
> contributing members and the board.
>
> Cheers,
>
> Rob
>
> --
> Email: robert(at)spi-inc(dot)org               Linux counter ID #16440
> IRC: Solver (OFTC & Freenode)
> Web: http://www.spi-inc.org
> Director, Software in the Public Interest (http://spi-inc.org/)
> Open Source: The revolution that silently changed the world
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general
>

--
henrik(dot)ingo(at)avoinelama(dot)fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc

My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559

Henrik Ingo writes ("Re: Draft of new associated-project-howto for review"):
> 2) A thing that is not mentioned at all is liability protection of
> individual developers.

This should be mentioned, but only to explicitly say that this is not
something that SPI offers to its members or associated projects. This
is so that SPI does not need to take charge of projects or become
involved in their governance (unless SPI is asked to, of course).

> Whatever the SPI's position on that is, it could be good to clarify.

Right.

> 3) Liaison
...
> This model has many advantages over a single self appointed person
> having all control, but doesn't really add any overhead in normal
> circumstances. I'd recommend to template this format and suggest it as
> an alternative (or the primary?) model of appointing a liaison.

I think a reasonable alternative model is:

* Alice Adams (and her successors) are currently recognised by SPI as
the authoritative decisionmakers for Gnomovision.

* In the event of any dispute within the Gnomovision project, SPI
will aim to
(a) abide by the consensus of the Gnomovision community
(b) act in the best interests of the Gnomovision project
[choose one]
provided always that SPI will honour the principles in SPI's
Framework for Associated Projects. If such decision is necessary,
it will be made, after public consultation, by the SPI Board.
The SPI Board's decision, as to who is recognised by SPI as the
authoritative decisionmaker for Gnomovision, will be final.

Ie I think the SPI Board should be willing to act as a governance
appeal body of last resort, if that's what the project wants. That
will avoid the project having to set up some kind of self-perpetuating
council or committee whose only purpose is to deal with SPI.

Obviously not every project will want this.

Ian.

(spi-private dropped from the CC list)

On Tue, Sep 20, 2011 at 6:05 PM, Ian Jackson
<ijackson(at)chiark(dot)greenend(dot)org(dot)uk> wrote:
>> 3) Liaison
> ...
>> This model has many advantages over a single self appointed person
>> having all control, but doesn't really add any overhead in normal
>> circumstances. I'd recommend to template this format and suggest it as
>> an alternative (or the primary?) model of appointing a liaison.
>
> I think a reasonable alternative model is:
>
>  * Alice Adams (and her successors) are currently recognised by SPI as
>   the authoritative decisionmakers for Gnomovision.
>
>  * In the event of any dispute within the Gnomovision project, SPI
>   will aim to
>     (a) abide by the consensus of the Gnomovision community
>     (b) act in the best interests of the Gnomovision project
>       [choose one]
>   provided always that SPI will honour the principles in SPI's
>   Framework for Associated Projects.  If such decision is necessary,
>   it will be made, after public consultation, by the SPI Board.
>   The SPI Board's decision, as to who is recognised by SPI as the
>   authoritative decisionmaker for Gnomovision, will be final.
>
> Ie I think the SPI Board should be willing to act as a governance
> appeal body of last resort, if that's what the project wants.  That
> will avoid the project having to set up some kind of self-perpetuating
> council or committee whose only purpose is to deal with SPI.
>
> Obviously not every project will want this.

An "appeal body of last resort" may not be a bad idea, or maybe it is,
but in any case this is not at all the same as I proposed. I think the
above is much fluffier and leaves some uncertainty:

Imagine a project with three active/core developers. One is the
self-appointed liaision. The liaison dies, and the remaining two core
developers start a bitter fight. How will the SPI board even be able
to know what is in the best interest of the project? It's to some
degree a subjective decision. It could even be a political decision
such as GPL vs BSD and whatever other dividing lines those two
fighting developers might represent...

For reference, the Drizzle Liaison process is here:
http://spi-inc.org/meetings/minutes/2011/2011-08-10/
... removing the names it could be easily templated as is.

henrik

--
henrik(dot)ingo(at)avoinelama(dot)fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc

My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559

Henrik Ingo writes ("Re: Draft of new associated-project-howto for review"):
> An "appeal body of last resort" may not be a bad idea, or maybe it is,
> but in any case this is not at all the same as I proposed.

Indeed, it is entirely different to what you proposed. It's a
different option and I'm not advocating it for your project or indeed
for any project in particular.

I just think it's a way of setting things up that's more lightweight
from the project's point of view, which some projects may prefer.

> I think the
> above is much fluffier and leaves some uncertainty:
>
> Imagine a project with three active/core developers. One is the
> self-appointed liaision. The liaison dies, and the remaining two core
> developers start a bitter fight. How will the SPI board even be able
> to know what is in the best interest of the project? It's to some
> degree a subjective decision. It could even be a political decision
> such as GPL vs BSD and whatever other dividing lines those two
> fighting developers might represent...

Indeed, what you say is absolutely true. The different between the
option I'm presenting and the "liason governing council" idea, is that
in the latter case the governing council must decide, whereas in the
former the SPI Board must decide.

As to how the board would decide: it would send a consultation - a
request for opinions - on the project's mailing list, and review the
recent mailing list traffic, and come to a conclusion. That would be
some work for the board but this kind of situation occurs very rarely.

Ian.