Should bug links in compat tables be kept after being fixed?

Sebastian Zartner

unread,

Jul 24, 2015, 4:44:35 AM7/24/15

to MDC Mailinglist

Hi all,

the subject already tells everything. Should links to bugs within the
compatibility tables stay there after it was fixed?

Current example:
https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports refers
to bug 779917 marking the implementation of that feature in Gecko.

Should it be removed now, since it's already fixed for quite some time
or should it stay there?

I'm also asking in regard of fixing the compat data importer issues,
because the importer is currently not able to handle those cases.

Sebastian

Jeremie Patonnier

unread,

Jul 24, 2015, 5:05:20 AM7/24/15

to Sebastian Zartner, MDC Mailinglist

I tend to get with the idea that if the bug provides no special info (it's
fixed and there is no known aside use case explain in the bug) we should
remove the link to the bug.

++
Jeremie

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide
> Doc project Trello board: https://trello.com/b/HAhl54zz/status
>

--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

Nickolay Ponomarev

unread,

Jul 25, 2015, 1:28:48 PM7/25/15

to Jeremie Patonnier, MDC Mailinglist, Sebastian Zartner

I'd like to ask that you keep the links to the bug somewhere on the page.
It serves as a reference supporting the information in the compat tables
and may provide useful information for other readers even if you don't
think it has any "special info".

Nickolay

Sebastian Zartner

unread,

Jul 26, 2015, 5:51:16 AM7/26/15

to Nickolay Ponomarev, MDC Mailinglist, Jeremie Patonnier

Ok, so now we have two different opinions. Personally I don't have a strong
preference, so I'll wait for another one or two comments to make a final
decision on that.
If the info should be kept, the only place I see would be within a
compatibility note.

Sebastian

Eric Shepherd

unread,

Jul 26, 2015, 7:13:09 AM7/26/15

to Nickolay Ponomarev, MDC Mailinglist, Jeremie Patonnier, Sebastian Zartner

Nickolay Ponomarev wrote:
> I'd like to ask that you keep the links to the bug somewhere on the page.
> It serves as a reference supporting the information in the compat tables
> and may provide useful information for other readers even if you don't
> think it has any "special info".

I personally agree with this; while many users don't need this
information, it can be a useful reference point for others. I wonder,
though, if there's any way it could be hidden if users just don't care.
Probably more trouble than it's worth to do that.

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshe...@mozilla.com>

Chris Mills

unread,

Jul 27, 2015, 2:00:05 AM7/27/15

to Eric Shepherd, MDC Mailinglist, Nickolay Ponomarev, Jeremie Patonnier, Sebastian Zartner

> On 26 Jul 2015, at 12:13, Eric Shepherd <eshe...@mozilla.com> wrote:
>
> Nickolay Ponomarev wrote:
>> I'd like to ask that you keep the links to the bug somewhere on the page.
>> It serves as a reference supporting the information in the compat tables
>> and may provide useful information for other readers even if you don't
>> think it has any "special info".
> I personally agree with this; while many users don't need this
> information, it can be a useful reference point for others. I wonder,
> though, if there's any way it could be hidden if users just don't care.
> Probably more trouble than it's worth to do that.

Could we include some kind of a little "compat history” list below the compat table, then create a template that collapses it and provides a little button to expand/collapse it?

Sebastian Zartner

unread,

Jul 28, 2015, 2:18:25 AM7/28/15

to Chris Mills, MDC Mailinglist, Nickolay Ponomarev, Jeremie Patonnier, Eric Shepherd

Just for clarification, with "compat history" you mean the history of how
the feature got implemented, not the history of edits to the compat data
for that feature, right?
I agree that the implementation history may be interesting for some users.
Though if we decide to keep that info, its display definitely would need to
be implemented in an unobtrusive way.
I see an issue regarding this, though: If the implementation history should
be saved apart from the notes, this probably requires some bigger changes
to the API, the importer and the articles, so the info can be distinguished
from general notes.

Related question:
Is there a way to search for something within all revisions of an article
or of all articles? Asking this, because there were already some references
to bugs and other implementation history removed before.

Sebastian

Stephanie Hobson

unread,

Jul 28, 2015, 1:23:07 PM7/28/15

to Sebastian Zartner, MDC Mailinglist, Nickolay Ponomarev, Chris Mills, Eric Shepherd, Jeremie Patonnier

There is already a way built into the API to show history :) Each browser /
feature combination can include information for any version of that
browser. I think bug number would end up in footnotes because there is no
place in the API specifically for it.

I would recommend that the bug get associated with a "non supported"
version of the browser. For the example Sebastian used that might look like:

5.0 Not supported [1]
22.0 Supported

[1] See bug 779917

I recommend the older version so that users who are trying to understand
current support levels don't think that they need to read through the bug
before they use the feature.

What I don't know if we have is a way to import that using the current data
import process, maybe someone else can speak to that?

Stephanie.