<div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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”.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Then it’ll be quite perfect. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Then the “right gremium” could make a decision to accept the pul request or not. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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! </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">I personally very highly value the work and the people around our common font format. Bright, attentive, and generally willing to make things better. </div><div dir="auto"><br></div><div dir="auto">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?). </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto">Adam</div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Sep 2020 at 10:57, Werner LEMBERG <<a href="mailto:wl@gnu.org">wl@gnu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br><br>> 10. I’d like to express my support for the notion that Behdad’s<br><br>> complaint is heard by a fair and impartial group of people with<br><br>> authority to change how OFF operates.<br><br><br><br>+1<br><br><br><br>Note that I very much value the helpfulness of many people especially<br><br>at Microsoft.  In other words, this my support of Adam's and Behdad's<br><br>concern is not a personal attack to anyone!  The main thing is that<br><br>the rules for the standard should not enable the domination of a<br><br>single company.<br><br><br><br><br><br>   Werner<br><br></blockquote></div></div>