RE: request a heartbeat publication of HTML5: Techniques for providing useful text alternatives

David Singer wrote:
>
> Using a heartbeat to do what it's supposed to do - document for
> everyone what the current status is, even if the status is not
> recognized as perfect - would seem worth doing.

Hi David,

I don't disagree that dating content has a value, but my concern still goes
back to the fact that "the most current" version (according to Steve) is at
http://w3c.github.io/alt-techniques/. Today that document has *NO* date
attached to it.

We also have http://www.w3.org/TR/html/embedded-content-0.html#alt which is
a W3C Proposed Recommendation dated 16 September 2014. Given its current
status, I can presume that it is fairly well "Locked down". (I have a
concern when Steve writes "... [it] is 2 years old and is largely obsolete".
I don't want to really be the one to ask, but why are we promoting obsolete
content through to a W3C Rec? And is it really obsolete, or is there just
that we have more to say now than we did back then?)

Finally, we have http://dev.w3.org/html5/alt-techniques/ a W3C Editor's
Draft dated 05 October 2012. Frankly, from my perspective this document is
something of an orphan today, but only because I follow along fairly
closely, know Steve and the work he has done here, and he's stated that the
most current document is the one on the Github repository. None-the-less, it
is my understanding that this is what is being considered/proposed to be
published as the W3C Note (somebody please correct me if I am wrong).


It still comes down to having multiple instances of the same (critical)
guidance spread over three documents, with each of the three documents being
slightly different (or significantly different?).

Which document are we talking about marking as the "heartbeat" version? The
one on Github that has no date at all? The moment we put a date-stamp on
that, we need to ensure that a frozen snapshot is available to any and all,
including those who do not walk the halls of W3C process each day/week. Do
we have that today, or a mechanism to do that?

If it is the dev.w3.org document, well, that has a time-stamp on it already
(October 2012) and Steve notes that he is not working on that any more (the
"heart" of that doc has stopped beating). Do we need to now say that as of
Oct 2014, this document dated Oct 2012 is still the state of the state - as
it mirrors what has been added to the CR HTML5, but, hey, also look over
here on Github, where things change on a dime?

I think that this also underscores my lingering concerns about talk over
"forking" and "living specifications" (especially the later). When every
commit to Github is a beat of the heart, then it sort of makes seeking
"heartbeat publications" somewhat anachronistic. I realize that this is a
HUGE topic, and I am sure it will be a large part of discussions at TPAC at
the end of this month; I have no illusions that it will be properly
addressed and solved on this particular thread.


However: I would propose instead that we look to do a couple of things here,
to clean things up a bit, and to address the spirit of what the "heartbeat"
is seeking to do (and again, correct me if I'm wrong, but one of the goals
of the heart-beat editions is to prove that things are still moving).

	1) Sunset http://dev.w3.org/html5/alt-techniques/ - in the
header/intro, change Latest editor's draft: to point to
http://w3c.github.io/alt-techniques, with a note under the Status of This
Document section that explains that ongoing work on this document has moved
over to Github, and that changes there are more 'fluid' and less constrained
by time stamping

	2) I think that commits to Github that are, in effect, 'published'
documents should include, on screen, the date of the current commit -
currently there is no date there at all, and I do not have a simple and
obvious way of ascertaining whether that content is older or newer than the
other documents that a simple Google search turns up. I think that is a real
problem.

	3) Given that commits happen 'when they happen', I think a table of
some key snapshot "builds"(*) should be made available, perhaps pointers to
the 1st day of every month, or something like Jan. 1, Apr. 1, July 1 and
Oct.1 snapshots - frozen moments in time that can be referenced easily(**).
As has long been said on the web, cool URLs don't change, and I would posit
neither should the content to those URLs.

(* we are not "building" anything, we are publishing documents, not code.
Back when I was doing consulting work to the Canadian Federal Government,
their internal standard insisted that all web documents have clearly marked
a "Last Updated" date - and they were prescriptive enough to insist on the
same exact location across all departments and divisions. As a government,
they were and are very experienced and accomplished on document
publication.)

(** I would go so far as to suggest that those commits might have a common
recall method across not only this document, but if we are going to the more
fluid publishing model at the W3C, all documents within the W3C: with a
common 'naming' convention it would become very user-friendly to find those
snapshots. Consider the following 3 URLs -
http://w3c.github.io/alt-techniques/2014-01-01,
http://w3c.github.io/alt-techniques/2014-04-01, and
http://w3c.github.io/alt-techniques/2014-10-01)


>
> The trouble with "a day here, a day there" is it's like my
> procrastination.  Months and years happen one day at a time. Let's try
> to beat our hearts (and not our colleagues.)

Well David, I'm not seeking to beat my colleague and friend Steve, and I
have offered a proposal above as a suggestion to address a concern I am
hearing. I personally have no issue with the TF, or PFWG, or anyone else
bringing forth a document with a date on it that says "this is where we are
today" - no my bigger issue is how do we manage that, given that the older
W3C 'publishing' method appears to be under deep scrutiny and review - do we
even need a "heartbeat" document anymore?

JF

Received on Saturday, 11 October 2014 00:19:14 UTC