Re: Proposal: moving tests to GitHub

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

Received on Wednesday, 23 January 2013 11:46:27 UTC