From: | Bdale Garbee <bdale(at)gag(dot)com> |
---|---|
To: | Jimmy Kaplowitz <jimmy(at)spi-inc(dot)org> |
Cc: | david(dot)pratt(at)tidesdk(dot)org, spi-private(at)lists(dot)spi-inc(dot)org, spi-general(at)lists(dot)spi-inc(dot)org, secretary(at)spi-inc(dot)org |
Subject: | Re: SPI resolution 2012.09.13.bg.1, TideSDK as associated project |
Date: | 2012-09-11 04:41:49 |
Message-ID: | 87mx0xkw6q.fsf@gag.com |
Views: | Raw Message | Whole Thread | Download mbox |
Thread: | |
Lists: | spi-general |
Jimmy Kaplowitz <jimmy(at)spi-inc(dot)org> writes:
> The same issue exists as in the OBF resolution - we should probably archive a
> copy of the relevant part of the TideSDK website and ask David, or
> failing that the TideSDK Team, to notify us when David's role or the
> Team membership changes.
The point of this clause is to allow those who are defined members of a
particular team at some arbitrary point in the future to be able to make
a decision and communicate it to SPI. We don't try to cache a list of
who's on the Debian keyring with power to elect the DPL, for example, so
I'm not sure why caching a copy of the current membership of the TideSDK
Team makes any more sense?
> Interesting also that the authoritative decision maker and the body which can
> choose another authoritative decision maker are distinct.... I'm increasingly
> agreeing with Ian that we should figure out a better phrase than
> "authoritative decision maker" and revise all of our project
> relationships, with consent of course, before any of our projects have
> a divisive succession battle.
I think if we recall that the decision making in question is in the
context of telling SPI what to do with project assets, and not some
arbitrarily large possible decision space in the project, the current
terminology works adequately.
Bdale
From | Date | Subject | |
---|---|---|---|
Next Message | Jimmy Kaplowitz | 2012-09-11 05:03:26 | Re: SPI resolution 2012.09.13.bg.1, TideSDK as associated project |
Previous Message | Jimmy Kaplowitz | 2012-09-11 04:19:14 | Re: SPI resolution 2012.09.13.bg.1, TideSDK as associated project |