- From: Mike Pennisi <mike@bocoup.com>
- Date: Tue, 4 Apr 2017 16:23:16 -0400
- To: public-browser-tools-testing@w3.org
> FWIW I think the main disadvantage of this is that it's hard to get an > overview; you have to dig into multiple issues rather than being able to get > a single-page summary. I think GitHub's "Milestones" feature addresses this need pretty well. Here's an example: https://github.com/tc39/test262/milestone/1 That page lists all issues assigned to the milestone (hiding the closed ones by default), along with a "percent complete" indicator. It also supports a "Due Date", which we could use to make the August 31 deadline [1] clear. [1] https://lists.w3.org/Archives/Public/public-browser-tools-testing/2017AprJun/0001.html On 04/04/2017 02:30 PM, James Graham wrote: > On 04/04/17 18:30, Mike Pennisi 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. > > FWIW I think the main disadvantage of this is that it's hard to get an > overview; you have to dig into multiple issues rather than being able > to get a single-page summary. I agree the spreadsheet isn't ideal > though (evidence: there are at least two and no one is keeping them up > to date. That might also be a problem with issues though). > >
Received on Tuesday, 4 April 2017 20:23:51 UTC