Re: WebDriver Test Suite

 > 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

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