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