On Wed, Nov 14, 2012 at 10:45:33AM +0100, Jiří Stránský wrote:
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
>>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.
I think that for trivial things like this you can go straight from pull to
autoack. As I did for the CNAME file and for some other trivial things.
And also is how Justin did during the conversion of the files.
>* For _structural_ or brand changes (e.g., changing the
> 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.
Indeed. That's the way to go. For that, in your last patch i commented out
that I wasn't sure about the changes on the news.
>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.
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
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
Indeed. But the point is that we don't have _yet_ a clear picture, we're
in "testing" environment so unless we don't have a clear picture on the
role, let's stick on the plan to see how things works.