On 23/01/2013 00:48 , Julian Aubourg wrote:
The one-repo idea, while much simpler from a maintenance point of view, could easily be a burden on users that subscribe to it. Even more so for people who can merge PRs (and thus will receive an email for a PR initiatedfor any spec).
It *could*. But we don't know that yet. Splitting is easy enough. So I reckon we can start with the simple, one-repo approach and if as it ramps up we find that produces too much volume in email (or any such thing that can be hard to manage) then we can cross the splitting bridge. One good thing is that the experiment might give us valuable information about what splitting lines make sense to our community. For instance, to take a random example, it might be that it makes sense to put all APIs together in one repo and all markup in another (I doubt that's the case, but it's just an example of a split that doesn't map to ours that could possibly emerge).
To put this more shortly: I'd rather only deal with the problems of actually getting a community now (for which a single point of rallying is helpful). I'll be overjoyed with having to deal with the problems that come with having built a successful community later.
And Tobie writed:
It's also worth thinking about which solution will have more chances of fostering a community of external contributors and reviewers. Strong but very specialized contributors might not get noticed. Being the biggest contributor to the XHR test suite might carry a lot more value than being the 50th biggest contributor to W3C tests in general.
This cuts both ways. Being the top contributor for a dozen smaller, less noticed APIs or features (e.g. Vibration, ruby markup) doesn't rate as high as being, say, 8th overall.
I certainly don't disagree that having a way of publicly recognising contributors (beyond peer recognition from those who track the PRs) would likely prove valuable. But again, I think that's something that we can shape as we go along. The requisite data is available through the API. You can extract overall contribution and you can filter it by root directories that it touched. I reckon we can get the same data irrespective of which approach we pick.
But, again, I'd rather we focused on getting it off the ground well and proper. When the gates get flooded we can reassess. At this point I should probably stop belabouring my point because I'm this close to using the word "agile".
-- Robin Berjon - http://berjon.com/ - @robinberjon
