Re: WebDriver Test Suite

I am definitely +1 on using GitHub for all the reasons mentioned in the thread.

> On Apr 4, 2017, at 1:26 PM, Mike Pennisi <mike@bocoup.com> wrote:
> 
> > If we do decide issues are the way to go, perhaps open them on the webdriver
> > project rather than the WPT? It seems far less than ideal, but it might make
> > things less noisy for non-webdriver specs.
> 
> That's a great idea! I probably sound like I'm selling something at this point,
> but GitHub supports closing issues via commit/pull request across repositories
> [1], so we'd still be able to cross-link in a way that makes our process
> discoverable. To be safe, we could also create a high-level "Test WebDriver"
> issue in WPT that references the spec's issue tracker.
> 
> I'd still be willing to set this up, but I would need to be made a collaborator
> on that repository. Would you be comfortable with that, Simon?
> 
> [1] https://github.com/blog/1439-closing-issues-across-repositories <https://github.com/blog/1439-closing-issues-across-repositories>
> On 04/04/2017 02:23 PM, Simon Stewart wrote:
>> If we do decide issues are the way to go, perhaps open them on the webdriver project rather than the WPT? It seems far less than ideal, but it might make things less noisy for non-webdriver specs.
>> 
>> Simon
>> 
>> On Tue, Apr 4, 2017 at 12:30 PM, Mike Pennisi <mike@bocoup.com <mailto:mike@bocoup.com>> wrote:
>> I think it GitHub.com issues would be ideal here? For those less familiar: they
>> can provide the same functionality as the referenced spreadsheet. That includes
>> 
>> - They can be marked "complete"
>> - They can be assigned to multiple people [1]
>> - They can communicate overall progress towards a milestone [2]
>> 
>> But they are improvements in a few important ways.
>> 
>> - They support conversations
>> - They are more closely tied to the tests themselves (can be referenced/closed
>>   via pull request/commit) [3]
>> - They support documenting incremental progress [4]
>> - They make changes (e.g. re-assignment) visible
>> 
>> Though maybe most important of all: they are far more discoverable. I don't
>> think potential contributors stand much of a chance of finding a spreadsheet
>> maintained by mailing list participants. On the other hand, when they see
>> relevant commits that reference a GitHub.com milestone, or they see a developer
>> making comments in an issue thread, they'll know where to go.
>> 
>> The only downside I can see is the volume of issues. As of this writing, there
>> are 276 open issues files against the WPT project. Creating one issue per
>> command would raise this to 329, which may be considered "noisy" by other
>> maintainers. We could mitigate this by creating issues on a per-endpoint basis
>> and lean on the "check list" functionality mentioned above.
>> 
>> If this sounds like a good idea, I'd be more than happy to follow up with the
>> legwork. What do folks here think?
>> 
>> [1] https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests <https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests>
>> [2] https://github.com/blog/831-issues-2-0-the-next-generation <https://github.com/blog/831-issues-2-0-the-next-generation>
>> [3] https://github.com/blog/1506-closing-issues-via-pull-requests <https://github.com/blog/1506-closing-issues-via-pull-requests>
>> [4] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments <https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments>
>> [5] https://github.com/w3c/web-platform-tests/issues <https://github.com/w3c/web-platform-tests/issues>
>> 
>> 
>> 
>