[MPEG-OTSPEC] Proposal to discontinue the AdHoc Group

[Adam Twardoch (Lists)]

I may be naive but my experience shows that when I have my “day job
responsibilities” but on top of that I’m also responsible for reading “free
prose” feedback for some text or code, and then I need to go open that
document, find the location, sweep through a backlog of additional “free
prose” comments and somehow distill the final amendment and put it into the
static document — I’d rather do my day job still.

The same experience with a pull-request-based Github process shows me that
I can, at all, be a maintainer of a document (text, code) in a way that’s
still work but that does not make me wanna run away.

Those technical documents (the spec plus other documentation) should be
treated like code. On Github, when I go like “well, that bit, maybe,
blah...” on some repo, the maintainer will often say “make a pull request,
then we’ll review it”.

I hope Github also adds a way to have inline discussions (comment threads)
on particular lines — with a neat UI, kind of like those bubbles in Word or
Acrobat.

Then it’ll be quite perfect.

I strongly suspect that at least a part of the problem is the antiquated
technical setup all those specs use. If I could fork and do my edits,
people could look at the proposed final wording in context of the entire
document, read, make an opinion.

Then the “right gremium” could make a decision to accept the pul request or
not.

This might all of course be a preliminary step to a more formal proposal —
just like software developers collaboratively develop a particular app, and
then make a release candidate, but then some other gremium decides that
it’ll be a release or not.

In software development, this is all solved. After I’ve seen how fontTools
or HarfBuzz grow in Github, I simply cannot think that doing it old-style
makes sense!

And I do mean Github. Git has been around longer but it’s been an arcane
tool for software devs. But the Github UI is making this workflow
accessible to less-technically-inclined people.

If we put a version of the source material on Github, and simply implement
the culture of issues, pull requests and (hopefully at some point) issues
that are visually linked to specific places in the “code”, my gut feeling
says that suddenly, it’ll be much easier for everyone involved, including
maintainers, to actually do the work.

Do I want to DECIDE what goes into the next version of the font format? No!
But I’d like to be able to use a tool to mark something, produce a proposed
rewrite myself, comment if needed.

I personally very highly value the work and the people around our common
font format. Bright, attentive, and generally willing to make things
better.

But I also know that things were left on the cutting floor more than once
because of insufficient capacity of the people charged with overseeing the
spec. And because of the legendary lack of modern tools to have a
discussion (opentype-l anyone?).

So I think: let’s build up the tools and a digital process, help those who
have the time to have a working copy of the material — and then, well,
there is still, always, the final instances, voting, whatever, that makes
the final call. After all, a file format is nothing if software makers
don’t adopt it. There is still a role for them.

There will still be proposals that will be left on the cutting floor. But
not because nobody had the time to pick them up and look at them properly.

Best,
Adam


On Mon, 21 Sep 2020 at 10:57, Werner LEMBERG <wl at gnu.org> wrote:

>
>
> > 10. I’d like to express my support for the notion that Behdad’s
>
> > complaint is heard by a fair and impartial group of people with
>
> > authority to change how OFF operates.
>
>
>
> +1
>
>
>
> Note that I very much value the helpfulness of many people especially
>
> at Microsoft.  In other words, this my support of Adam's and Behdad's
>
> concern is not a personal attack to anyone!  The main thing is that
>
> the rules for the standard should not enable the domination of a
>
> single company.
>
>
>
>
>
>    Werner
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200921/dbaf26d9/attachment.html>