Website Cabal

Jiří Stránský jstransk at redhat.com
Wed Nov 14 09:45:33 UTC 2012


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.



More information about the aeolus-devel mailing list