Re: ReSpec and how it gets used

Comments in line

On Tue, Jun 7, 2016 at 2:11 PM, Markus Lanthaler <markus.lanthaler@gmx.net>
wrote:

>
> >> browser is over 2 years old now, and has been superseded by Edge).
> >> Either kindly ask your users to switch to Edge
>
> Well, that might be tricky for lots of users as it also requires an OS
> update.
>

Agreed.  Moreover, this is not an option for many users (see below).


> >> or use a more modern browser ... alternatively, please publish the
> >> ReSpec output instead, which should work on any browser going
> >> back to IE6.
>
> I'm not going to ask to start supporting IE11 again but what browser
> support do you aim for? Only the absolute latest version? IE11 still seems
> to have a considerable market share...
>


We have no clear guidelines on this  My inclination is to never break faith
with backward compatibility unless maintaining it forces a reduction in
primary function.  I suspect we have made a mistake removing whatever
polyfill enabled IE11 support.   And while I agree with some other
commenters that publishing static versions is a better end user experience
anyway, the reality is that many working groups are developing specs using
ReSpec, and those groups don't want to take the time to generate static
versions - in particular for their "Editor's Draft"s.  So to the extent
that we want people to be able to readily review specs as they are in
development, we need to take this into consideration.

Note that I am not talking about the people writing the specs.  I assume
they are working with relatively modern user agents.  They are typically
geeks like us.  But their constituents are often less tech-savvy.  The Web
Payments community, for example, has A LOT of bankers in it.  Conservative
organizations tend to lock down software and only upgrade rarely, and then
after acceptance testing.  But they are nonetheless members of the W3C, and
should be able to review and comment on our specs.


>
> > As a reader of ReSpec'd specs, I'd highly appreciate it if more people
> > published the generated output instead of the sources.  It avoids the
> > flash-of-unprocessed-content and subsequent anchor-jumping, and it
> > works better in the tooling infrastructure.
>
> The thing I like most about ReSpec is that it doesn't need any
> "compilation" step. It's not perfect but for most use cases it works well
> enough.
>
>
Yes.  It is what drew many of us to ReSpec.  The recent instability has
made it a much less desirable platform.  My groups have spent a lot of time
trying to resolve ReSpec introduced problems or learning new requirements
as features change.   Worse yet, various changes have broken the tool chain
that enabled the automated generation of "TR" versions of specs or
otherwise made it impossible to publish without hand-editing.

As a maintainer of ReSpec, I am appalled.  As a user, I am frustrated.  As
an advocate, I am finding it a hard product to recommend.

Perhaps the solution is to make all the (named) versions available so that
document developers can choose the one that works well for them and their
users?  Or identify a stable version and call that official, then leave the
"development" bleeding-edge that people can use or not.  Do a migration to
stable periodically after substantial testing. I don't know.  But something
needs to change.  Right now I see the best case as people forking ReSpec so
they have something they can rely upon.  I see the worst case as them
abandoning the platform. Both of these would be a failure.


-- 
Shane McCarron
Projects Manager, Spec-Ops