Re: Web Platform Tests Pull Request Commenting

Just a note to say that the text description of the data model I promised
last week is now in the document
<https://docs.google.com/document/d/1HK5roexqU2Nd2iTMKO4UM5Gc3b5vuFm06J3E06iGcxM/edit?usp=sharing>
for your perusal. Writing it up exposed a couple of bugs that I have
resolved in the data model diagram..

On Thu, May 18, 2017 at 11:48 AM, Bob Holt <bob@bocoup.com> wrote:

> Since my email yesterday, I've been working on the data model required to
> do everything we would want in the PR dashboard (building on one James
> began). I have added it to the bottom of the specification document
> <https://docs.google.com/document/d/1HK5roexqU2Nd2iTMKO4UM5Gc3b5vuFm06J3E06iGcxM/edit?usp=sharing>.
> I will write up a text description explaining the reasoning behind the
> entities and their relationships, but I will say that in looking at the
> potential complexity here, it looks more and more like a standalone
> application.
>
> On Thu, May 18, 2017 at 9:58 AM, James Graham <james@hoppipolla.co.uk>
> wrote:
>
>> On 16/05/17 19:19, Jeff Carpenter wrote:
>>
>>> I certainly don't want to step on any toes here, but I wanted to throw
>>> my opinion out there since I see possible opportunities for saving time
>>> and effort. From my perspective it looks like the project I'm working
>>> on, WPT Dashboard, and this project have very similar aims:
>>>
>>> - WPT Results Consolidator: Collect and display WPT results
>>> - WPT Dashboard: Run, collect and display WPT results
>>>
>>
>> So, I think that's a simplification of the situation.
>>
>> The stability dashboard will need to show multiple runs for a specific
>> test. It will only need to deal with one PR's worth of tests vs the
>> hundreds of thousands of tests in the entire repository, which vastly
>> changes the kind of visualization options that are required. It will need
>> to show additional information like where the PR is synced on
>> w3c-test.org. It will need to draw attention to anything that blocks the
>> PR from landing, but won't necessarily need features like search that are
>> required to work with the full set of results.
>>
>> I definitely see the appeal of sharing code where it makes sense, but I
>> wonder if in this case it won't be more effort to try and make one tool
>> that does everything well vs two tools that do a specific thing well. I
>> think I would need to see a concrete proposal for how we could build a
>> single tool here to judge better whether the tradeoffs are worth it.
>>
>>
>>
>