W3C home > Mailing lists > Public > spec-prod@w3.org > January to March 2021

Re: Feedback sought on reorganizing the list of W3C Technical Reports

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 12 Jan 2021 17:59:36 +0100
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, spec-prod <spec-prod@w3.org>
Cc: "public-website-redesign@w3.org" <public-website-redesign@w3.org>, Denis Ah-Kang <denis@w3.org>, "vivien@w3.org" <vivien@w3.org>
Message-ID: <ea3d3eda-5981-11ae-d726-13177a54a0f9@w3.org>
Le 11/01/2021 à 13:21, Nigel Megitt a écrit :
> Realistically, for this human, 280 and 1200 are pretty much the same degree of "hard to navigate".
> 
> I like the idea of grouping and categorising. You'll likely find overlap between groupings regardless of what classification scheme you define. For example folk interested in video media may well want to know about timed text, but folk interested in timed text may want to know about CSS or SVG, for example.

I had initially tried a more curated/editorial approach to
classification (which would help with guiding potential users based on
their interest); but from that experience and past experience in this
space, it feels like it would be challenging to create *and* maintain
such a categorization (partly, this is what we tried to do in the 2008
redesign with the so called "tech groups", which had to be later
abandoned for lack of take up from the groups).

This is why I chose to proceed with a less ambitious but more easily
systemizable approach of grouping specs that are more or less
unambiguously part of a single set, with room for further guidance from
groups.

> Maybe a tagging and filtering approach is more useful than a strict classification grouping, because it allows any report to be findable via different routes. It also allows more useful groupings, if they are found later, to be added without breaking existing groupings.

The TR page already has tagging and filtering, and I expect this will
remain true in the redesign; from my early discussions with Denis, it's
likely that the tags could be applied at the family level (but we
haven't verified that yet).

> On a specific point, if you're using families, then for the TTML and WebVTT families, it probably makes sense just to make a "Timed Text" (super?) family.

I agree they would form a logical "super family"; but I'm hesitant to
create a hierarchy of family at this stage.

> It may be useful in general (but not always) to be able to group by the Working Group that published the docs. This may be possible already via other routes, but it's an obvious source of tags to define first order groupings.

There are already views of specs by groups, e.g.
  https://www.w3.org/groups/wg/webrtc/publications

Are you suggesting the TR page itself should provide such a grouping
directly?

(in any case, I agree with you that in many cases, groups provide useful
hints for grouping, whether at the tag or family level)

> I like the "in progress" vs "completed" distinction as a concept, but how does it work with Recs that can have new candidate features added? Isn't that a Rec that's always "in progress"?

Great remark! I think a Rec with candidate/proposed changes would
probably be marked as "in progress", but I welcome input on this.

Dom
Received on Tuesday, 12 January 2021 16:59:40 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 12 January 2021 16:59:41 UTC