On 13.11.2012 15:48, Matt Wagner wrote:
On Tue, Nov 13, 2012 at 09:05:50AM -0500, Mo Morsi wrote:
> On 11/12/2012 12:07 PM, Justin Clift wrote:
>> Mo, would you like to be on the website cabal?
Mo ^ ?
> Since the website doesn't require much verification other than viewing
> it and manually making sure it looks good, can't we just push updates to
> the website?
>
> Or perhaps send pull requests, but unless there are any critical
> objections, those get automatically ack'd after 2 or 3 days? (comments
> and suggestions on the pull request should be addressed but after that
> they shouldn't be considered critical objections unless explicitly
> indicated). Of course explicit ACKs can be pushed immediately.
Personally, I'd advocate something more like the following:
* For content changes, send a pull request. If you don't get a response
in a reasonable time, pushing it yourself is fine.
* For _structural_ or brand changes (e.g., changing the navigation
items, changing the theme of the site, updating slogans...), an ACK
from someone else should be required. More importantly, the changes
should have been discussed ahead of time with the Cabal.
I think we want to make it as easy as possible to keep the site
up-to-date, so allowing a self-push if you get no reviewers seems
reasonable to me. (After all, our problem is that we don't have people
making updates, not that we have people making erroneous updates.) But
for big, structural changes, I think chaos would reign if they weren't
well-communicated with the group.
+1. Pull request with some timeout for small (content) changes, but prior agreement for
big (structural etc.) changes.
(Honestly, I'm not sure what I said is actually any different from what
you meant.)
> That way the website is continuously being updated and if someone
> doesn't like a change they can easily send an additional pull request
> and push additional patches ontop of those changes.
+1
> Perhaps in the case
> of differences in opinion, Hugh (or whoever he designates) can have the
> final say.
I'd like to think that this won't come up, though it's probably good to
think about ahead of time. I'd like to say that, in the event of
disagreement, we should discuss and vote on it within the committee. If
we can't resolve it (i.e., if there's not broad consensus), we should
probably take it to the Technical Cabal, since they seem to be the chief
decision-making body.
I believe disagreements (if there are any) should be solved by voting on respective
cabals. I'd say it shouldn't go to Hugh/Angus/Mike in most cases, and website
problems really shouldn't go to Technical Cabal. Tech cabal should solve tech stuff
(APIs, conventions, making sure components work together), we should solve website stuff.
We will probably have to communicate sometimes with Publicity Cabal, as we have some
overlap, like blog/news for example. (So +1 for you being on both, Matt, to facilitate the
communication.)
The point of cabals, as I understand it, is to have more self-sufficient project
governance. I think Hugh said he wanted to make Aeolus less dependent on management, but
also avoid chaos and endless discussions. Cabals should make Aeolus more of a community
project, yet keep the ability to steer the project in a sane way.
Just my 2c :)
J.