Re: Proposal: moving tests to GitHub

I can't guess how important the whole "attribution" thing is. I can however
say that having a public repository on github makes it easier for
"drive-by" contributors to contribute something. The traditional process
captures almost none of these contributions. I can also tell that I (and
probably most drive-by contributors) aren't that interested in attribution,
we just want to have our tiny contribution jotted down at the right place
and then be done with it.


On Wed, Jan 23, 2013 at 12:46 PM, Robin Berjon <robin@w3.org> wrote:

> 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
>
>