- From: Mike Pennisi <mike@bocoup.com>
- Date: Tue, 4 Apr 2017 13:30:56 -0400
- To: public-browser-tools-testing@w3.org
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 [2] https://github.com/blog/831-issues-2-0-the-next-generation [3] https://github.com/blog/1506-closing-issues-via-pull-requests [4] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments [5] https://github.com/w3c/web-platform-tests/issues
Received on Tuesday, 4 April 2017 17:31:33 UTC