search

MPEGGroup / OpenFontFormat

Official MPEG repository to discuss issues on Open Font Format (ISO/IEC 14496-22)
32 stars 6 forks source link

Add LICENSE.md file #1

Closed davelab6 closed 4 years ago

davelab6 commented 4 years ago

It isn't clear what license contributions to this repo are made under, both to the issue tracker, and to the files repository itself.

Here are other MPEGGroup repos with license files:

ISO directive notices

This is impenetrable and I don't like it, but I suppose this is what is most likely to be appropriate.

BSD

This is better, but its rather long... Also, the notices are for "Copyright ISO" but this repo would I guess have "input candidate" files owned by their authors, so I could suggest no notice, and just the license text itself...

MIT

This is recognized by the Github web app (nicely formatted summary at the top) and is what I would recommend (with no notice)

If there are subfolders in this repo where eg a python package is authored, I think it would be fine to have a LICENSE.md file within that folder like this, supplementing the above "ISO directive notices" file

vlevantovsky commented 4 years ago

I will consult with other folks to see what can be adopted as a license here, but the fact that we may have to abide by the ISO policies and Directives could be a necessity.

dwsinger commented 4 years ago

Generally I am surprised to find licenses on these repos; public Github repos for ISO-related projects should be for discussion only, not contribution.

davelab6 commented 4 years ago

@dwsinger isn't a MPEG group repo a good place to contribute WG inputs?

dwsinger commented 4 years ago

ISO doesn't admit the existence of these repos, and any impact on specs would have to be in the form of contributions, written, to the group, or national body comment if the spec. is out for ballot. it's dangerous to have someone lift ideas from a public repo and put them in a contribution document, as this loses traceability.

I'm just advising caution; if we get to the point where a conversation suggests a technical contribution, I think we can work it out. I don't think it's a good idea to imply that technical work on ISO specs. can happen here, that's all.

alerque commented 4 years ago

I don't think it's a good idea to imply that technical work on ISO specs can happen here.

If you don't make a way for technically minded people to use technically appropriate technology to collaborate on their work then meaningful technical progress is going to be kept to a minimum.

dwsinger commented 4 years ago

I think that there is a lot that can be achieved through community discussion, and that's fine. Why don't we get to the point where someone wants to make a technical contribution to the ISO spec., and then we can work out the clean way to do it?

davelab6 commented 4 years ago

@dwsinger I think you are massively underestimating the volume of changes that are incoming. I'll post to the mpeg-otspec list about this now.

davelab6 commented 4 years ago

ISO doesn't admit the existence of these repos

I'm surprised to hear that. Do they admit the existence of the mpeg AHG email lists on an Austrian university server?

and any impact on specs would have to be in the form of contributions, written, to the group, or national body comment if the spec. is out for ballot.

The members of the AHG who aren't members of the WG can submit written contributions to the WG via the chair, though, right?

I'm failing to see any difference between documents attached to emails sent to the Austrian university listserv, and documents sent to an official mpeggroup GitHub repo via pull request.

it's dangerous to have someone lift ideas from a public repo and put them in a contribution document, as this loses traceability.

GitHub offers a convenient UI to "git blame" which provides line by line, second by second timestamping of contributions to a document for extremely thorough traceability.

Attachments to an email seem much less traceable to me.

I'm just advising caution; if we get to the point where a conversation suggests a technical contribution, I think we can work it out. I don't think it's a good idea to imply that technical work on ISO specs. can happen here, that's all.

The current process seems worse.

behdad commented 4 years ago

I'm surprised to hear that. Do they admit the existence of the mpeg AHG email lists on an Austrian university server?

See, that's the core of my complaint. That there is no way to contribute to OFF other than getting MS to want to.

vlevantovsky commented 4 years ago

@davelab6, @behdad - I find these type of comments disheartening and counterproductive. You both have seen the official list of AHG mandates shared on the AHG email list, you both KNOW that the mandate that establishes the AHG on Font Format prescribes us to use the email list hosted by AAT as our official communication channel (and not just us, all other AHGs established by MPEG Working Groups use the same AAT email lists server) - making comments implying the invalidity or impropriety of officially established AHG communication channel is misleading and ill-advised! And you both do it knowingly, which is troubling, to say the least.

behdad commented 4 years ago

@vlevantovsky Stop communicating with me.

alerque commented 4 years ago

@vlevantovsky I feel like you're stonewalling: on this issue and indeed everything surrounding the OFF process. I spent half my day catching up on the mailing list traffic — partly through emails found in my spam folder and the other part which didn't even get delivered as far as spam though the web archives. The list server is both broken technically and a disaster as far as a venue for collaborative technical development goes. It's no good for what the people with ideas, frustrations, technical skill, motivation, and energy right now want to try to accomplish. Maybe it doesn't bother you personally, but you're not in the same position all the rest of us are. At this point it seems like half the emails are from you saying there are no problems and everything has always gone well and the other half is people trying (and failing) to solve problems you don't acknowledge exist.

https://github.com/MPEGGroup/OpenFontFormat/issues/1#issuecomment-682109689

vlevantovsky commented 4 years ago

@alerque If you look at README, it describes the suggested process on new change proposal that actually took into consideration your comment.

However, we also need to satisfy the requirements of the ISO process, where every change in the specification has to have a documented trail that can be tracked: a proposal or a ballot comment > the WG resolution or the disposition of comments > spec change (if accepted).

In the past, the proposed changes were always discussed in the AHG and have been submitted to WG either as individual member contributions or as collective AHG contributions, both accompanied by an AHG recommendation to WG to adopt those changes. Strictly speaking, the preliminary discussion of a proposal in the AHG is recommended but not required - any WG member can submit an input contribution to the WG directly. What happens next depends on the WG decision.

Since the membership in the AHG is open to general public, we have always considered this to be the community venue by which proposals can be developed and presented to the WG from a diverse group of experts who may not have an opportunity / ability / resources to directly participate in the ISO WG work, but anyone can become a WG member and choose to make direct contributions.

alerque commented 4 years ago

I saw the content of the README. I does not address the substance of my comment.

What you're offering:

  1. Copy bits of a document in a format that isn't readily editable and quote them inline in an issue using inevitably different formatting from the original.
  2. Discuss, where each participant also copies bits of content into their replies but nobody can get a diff either from the original or from each other's comments.
  3. Copy and paste whatever bits are considered the outcome of said discussion back into emails to a list server that only even sends mail to some subset of list members and try to convince somebody to take it wo the WG.
  4. Submit everything to a blackbox process of people that have no exposure to the original discussion(s) and also can't see clear diff's because everything is being done in Word & and some proprietary home grown XML schema, also evidently not tracked under version control.

Vs. what developers these days expect:

  1. Fork/branch the current content and make changes directly on the source.
  2. Open a pull request with clear diffs of exactly what changes.
  3. Allow line by line comment including accepting edit suggestions to tweak the changeset.
  4. Somebody decision making process eventually approves (or rejects) and the PR is merged (or closed).
twardoch commented 4 years ago

That’s right. And what you’re describing is actually perfectly trackable. Github runs on git, and git offers a blame function that can identify the author of any particular change. That’s gives very detailed insight into the origins of the changes, much more than a single-person edited Word document!

Thrn: those accepted changes can be pooled into a “release” (in Github terms), i.e. “proposal” (in ISO terms).

Such proposal can be then formatted on a format that is acceptable to the ISO WG (such as .docx if needed, or some other format). Basically that's an equivalent of a compiled software “release candidate”.

That “compiled” proposal is turn submitted to the ISO WG for discussion/voting etc. Yes, it’s an ISO process.

twardoch commented 4 years ago

@vlevantovsky Quite a few of us understands that ISO requires tracking of changes. It so happens that professional software development also requires that, and is extremely strict about that.

Github offers a collaborative system where you can give out permissions, track the changes, preview them in a consolidated fashion. It offers branches that allow different major rewrites of some portions independently of other portions, rather than working on a “live copy” all the time.

With Github, you can also perform project management, identify milestones. You can tag issues with different statuses and close them if they are resolved.

Finally, there are ways to build “compile” the documents from a source version to a final presentable version, presentation of which can be fine-tuned and controlled, including good typography.

Images can be automatically converted from some format to another (for example from SVG to a EMF or PNG that is included in the compiled .docx).

There is nothing technical that prevents is from using Github for the AHG work and preparation of deliverables to the ISO WG. On the contrary, this will make the process better.

If there is a current mandate that prescribes using some other technical means — what needs to be done so that that mandate is changed?

vlevantovsky commented 4 years ago

Yes, this would've been a solution if we had a license to freely edit the source - we don't. Also, part of the ISO process is that each document has the editor that is assigned to do this job, and he/she/them is the only party that can change the document and make edits based on the WG resolutions / decisions and/or ballot comments that the WG resolved to accept. What you're proposing would be exactly backwards - first we make changes, then we accept them, and only then we would propose that ISO should resolve to accept them as well.

I honestly doubt this would ever work - if ISO allows anyone to edit the standard, it would stop being the standard.

twardoch commented 4 years ago

Actually, on the contrary :) The pull requests don’t merge themselves, and the projects don’t manage themselves.

But perhaps the job might involve less of the boring copy-paste-clean formatting in Word, so that Vlad can actually focus on the merit aspect of the changes (consistency etc.).

Working with Github is pleasant, and setting up there necessary software is easy.

behdad commented 4 years ago

WOW. VLAD JUST DELETED MY COMMENT!

I had said: "In other words, Vlad will not have a job."

behdad commented 4 years ago

so that Vlad can actually focus on the merit aspect of the changes

He's not qualified to.

vlevantovsky commented 4 years ago

@behdad You are in direct violation of the ISO Code of Conduct! Disrespectful behavior will not be tolerated.

behdad commented 4 years ago

How is saying that you won't have a job is "disrespectful" in an issue where we are discussing process?!

dbuenzli commented 4 years ago

What you're proposing would be exactly backwards - first we make changes, then we accept them, and only then we would propose that ISO should resolve to accept them as well.

Isn't that "backward way" the way the Unicode standard is actually maintained in sync with ISO 10646 ?

May be worth checking out the process they have to do that (I don't know, and the unicode FAQ doesn't mention the actual process).

alerque commented 4 years ago

Yes, this would've been a solution if we had a license to freely edit the source - we don't.

What do you mean by this? I don't know what you mean by "freely" — we're not proposing a free for all willy-nilly edit process here.

What license is the OFF spec document under? Whatever that is could be the answer to this issue: document what the license is and that any snippets, discussions, and PRs here would be released as that (or something compatible) so that there is an open path to inclusion later. Problem solved, and at least we could keep a simple glossary here (see #14) for starters.

What you're proposing would be exactly backwards -

Nope, you're the one with the backwards process. It's full of back doors, closed rooms, secret votes, un-editable documents, mailing lists that don't accept attachments, issue trackers that exist but you "don't acknowledge their existence", and other barriers — most non-corporate players don't have a viable path to contribute. Right now our best bet seems to be to get one of the major vendors to adopt our idea and push it through using their back doors.

I honestly doubt this would ever work - if ISO allows anyone to edit the standard, it would stop being the standard.

Again, this suggests you're not listening to the problems the rest of us see in the process. Of course there has to be an approval process and of course it has to include more than a few randos on the internet. But there is better technology to use in collaborating on technical documentation than word docs and mailing list that strips attachments. Any good VCS (it doesn't even have to be GitHub) open to public contribution but with proper curating would do wonders for the standard — both documenting what exists and developing new things. If you don't see the advantages of modern VCS tooling and doubt using them would ever work maybe you're not the best one organize this.

Pomax commented 4 years ago

@vlevantovsky it sounds like you are unfamiliar with how github actually works. That's a problem, but it's also something that we can solve and doesn't need to stand in the way of progress.

Fundamentally:

It sounds very much like there is a drastic misunderstanding about how git and github work. That can be solved by (1) educating yourself by reading up on how they work (github has really great guides for doing just this on the website), and (2) listening to people when they explain how this system works.

Reading through this thread, right now it sounds like the people who should know how git/github works, you included, don't. And that's a problem for literally anyone who wants to help you and the standards body improve the state of affairs. Don't shoot them down, listen to them, and learn from them. Because right now your comments seem to come from a place of misunderstanding about the very nature, capabilities, and process, of the medium that you're posting comments through.

twardoch commented 4 years ago

Yes, this would've been a solution if we had a license to freely edit the source - we don't. Also, part of the ISO process is that each document has the editor that is assigned to do this job, and he/she/them is the only party that can change the document and make edits based on the WG resolutions / decisions and/or ballot comments that the WG resolved to accept. What you're proposing would be exactly backwards - first we make changes, then we accept them, and only then we would propose that ISO should resolve to accept them as well.

I honestly doubt this would ever work - if ISO allows anyone to edit the standard, it would stop being the standard.

Nobody except the ISO can “edit the standard”, because the standard is controlled by ISO. The standard is not just some text document. It’s the text document with an ISO “stamp” — and nobody is arguing that we change that.

I’m talking about editing the text that will be submitted as a proposal. This is no different than Peter Constable editing the text of the OpenType spec, or people like Behdad writing the text of the COLR proposal, or Sairus Patel writing the text of the CFF2 proposal.

They all created and edited a non-normative (from the ISO POV) text, which then was submitted to the AHG, and you incorporated those changes into the ISO working draft.

For completely new proposals, this is workable. But for revising the text, retyping large portions of an already existing document in order to reformulate some paragraphs, and then submitting them so that someone (you) again incorporates that into the working draft — that’s actually a very error-prone, tedious procedure.

And describing the proposed changes using copyediting methods from the 1940s (“after the second comma in the third sentence, remove ‘or’ and insert ‘and’”) is, IMO, unworthy of developing the cutting-edge technology.

Some parties (Adobe, Microsoft) have privileged access to working copies of documents that are often a “search/replace step away” from the ISO standard. (Search for “OpenType”, replace with “OFF”).

Other parties do not.

twardoch commented 4 years ago

I realize that ISO has a business model and it sells the text of the standards. But let's face it: OFF is not a bestseller. First, the PDF is available free of charge as one of the publicly available standards.

Second, most people refer to the MSOT documentation anyway, not the OFF text.

There may be some group that buys the ISO OFF anyway, and they'll but it even if the source working drafts are available. Because they pay for the ISO stamp.

davelab6 commented 4 years ago

Vlad, if the repo isn't official, we can add an Apache license and start collaborating on unofficial documents here?

behdad commented 4 years ago

I realize that ISO has a business model and it sells the text of the standards. But let's face it: OFF is not a bestseller. First, the PDF is available free of charge as one of the publicly available standards.

Adam, see:

https://twitter.com/behdadesfahbod/status/1283098899784142849?s=19

dwsinger commented 4 years ago

Yes, ISO sells documents. Yes, they have a process by which standards are developed and approved. Many countries automatically make ISO standards into national standards, for example; so they are careful. Yes, ISO owns the copyright in the ISO spec. We should respect that. Yes, ISO has some people who like process and rules and sticking by them. No, we can't change ISO very easily (trust me, I have tried).

Yes, we can have all sorts of discussions about what we'd like to happen. Yes, many of them can happen anywhere. But recommendations of what happens at ISO should have a history on the published AHG list, so anyone can see the archives and who was in the discussion and how it went. There's a lot of openness possible. But we shouldn't step over these fairly mild lines, I think; it has a risk of raising antagonism to not much useful effect.

yes, we could consider alternative ways to develop and publish. But we won't make friends if we go from a confusing situation of two specs (ISO and Microsoft) to a confusing situation which adds a third, so I think consensus and being aware of boundaries will help us in the long run.

vlevantovsky commented 4 years ago

I think you are vastly overestimating my powers (there are none) and my ability to influence any decisions related to the ISO process. I do not hold any official position other than being a member of the WG that nominated me to serve as a chair of the AHG and as the project editor. This is not a job, this is a public service. I hear your frustration about the ISO process but have no means of changing it, or influencing someone who can.

This repo is not established by ISO, it is not recognized by ISO, it was intended to be used as issues-only repo to facilitate the discussions (see this earlier comment for details). The text of the ISO standard is not licensed to be copied or edited by anyone. The only license you get is the one you click through when you download your publicly available copy of the standard (you can find download links in README).

ISO, or any of its subcommittees operate based on the established process, and this is not something we can change. As I see it, if we want to get the job done (i.e. to update and improve the existing ISO OFF standard), we have to follow the established process. Yes, it's cumbersome, but it worked for this community for the last 16 years. How we generate the proposals to make particular changes in a particular clause of the OFF standard is totally up to an individual (or a group of individuals) proposing the change, but in order to get it considered it needs to be submitted to the WG in a format they expect, and using the process they adopted.

davelab6 commented 4 years ago

recommendations of what happens at ISO should have a history on the published AHG list, so anyone can see the archives and who was in the discussion and how it went.

But the mailing list trashes attachments, and can't deliver email reliably. GitHub is much more reliable as a published forum.

in order to get it considered it needs to be submitted to the WG in a format they expect, and using the process they adopted.

That's a separate topic to the collaborative drafting on the submissions.

twardoch commented 4 years ago

@behdad If OFF is a “best seller”, that actually makes my point even stronger: ISO sells OFF (directly and through the national standards bodies which have their own online stores) despite the fact that it’s also available for free, and that it's currently pretty much a lagging-behind subset of MSOT spec that is also available for free.

*Free to read, that is.

Certainly it would continue to be a best seller:

People who buy ISO standards want to have ISO standards that they have paid for. I see it as a rough equivalent to paid support or paid certification.

The problem is though: right now those customers are paying for a product of very low quality! The parent spec (MSOT) is full of holes, editorial, logical, technical. Those holes may be worthy of Swiss cheese, but not of a Switzerland-based standard.

We’d like to improve ISO’s product, ISO will get a much better product they can sell (if the WG approves ofc), and ISO won’t have to pay. How cool is that! 😄

davelab6 commented 4 years ago

This repo is not established by ISO, it is not recognized by ISO, it was intended to be used as issues-only repo to facilitate the discussions

The point I made at the top is that if I post some text in this repo, with the intent that others collaborate with me on drafting that text, that collaboration requires a license in order for them to modify it.

That is true if the text is published on the issue tracker section of the repo, or as a file within the file section of the repos

davelab6 commented 4 years ago

@twardoch said,

for revising the text, retyping large portions of an already existing document in order to reformulate some paragraphs, and then submitting them so that someone (you) again incorporates that into the working draft — that’s actually a very error-prone, tedious procedure.

It's fine. We need to rewrite everything anyway. There are benefits to a clean slate.

For each section, we will write and submit to the AHG and WG a new section draft. That new text can live anywhere in the internet, in an unofficial capacity.

I believe this repo is the best place.

dwsinger commented 4 years ago

@davelab6 you're arguing that more modern tools are better than email mailing lists. That is true, but not where we are, and a long way from where ISO is.

twardoch commented 4 years ago

@dwsinger I myself understand that it's not easy. I respect ISO, their business, also the fact that it's a bit slow and ineffective — but the fact is that it also is a genuine forum for various country delegations to at least in theory have influence on the process of shaping various aspects of technology and other areas of life.

But I would still argue that OFF is a bit special:

All those hidden references are extremely opaque. MSOT was never given proper editorial care because writing the spec was always a side-job of someone at Apple, then MS. Those people went away, others came. The quality of the writing and the internal consistency deteriorated.

In an effort to be technically equivalent to the mainstream font format spec, OFF took over that baggage. So from a (mild expletive) spec came a mediocre standard.

The past process may have been ok within that scope. And it probably would be ok if the changes into OFF came from a a good document. But it comes from a poor, insufficient, confusing document.

The truth is: if someone today buys ISO OFF with the faith that this standard will lead them in implementing a new technical solution for dealing with fonts — they will be very disappointed.

“We followed the standard.” “Are you crazy? You should not follow the standard! You should e-mail Greg!” “Who’s Greg?”

I feel old by knowing at a blink of an eye who Greg is (and Dave O, and Sampo, and and and...)

But younger developers don't know, and they shouldn't. They should be able to implement a standard/spec and that should give them a good result.

Otherwise, implementations are inconsistent , since there are more implementations, they'll be more inconsistent. Fonts will work less reliably, font creation software vendors will struggle even more with this fragmentation.

By being of so low quality due to its complicated heritage, OFF is not providing a good service at all. So it's providing an illusion of a standard.

Is this really what we want? If so, what's the point for OFF to exist?

I realize that the wheels of ISO are turning slow. But it's evident that there is some flexibility. After all, we have an AHG and in the past, changes into OFF were submitted from non-ISO entities (like MS or the W3 OpenType in SVG CG or Apple). So it seems that there is some process to be upheld but not everything is set in stone.

I understand that in case of a “core" standard, ISO should be conservative. But OFF isn't really a core standard. Nobody (I think) really implements ISO OFF. So the cost of trying something new might be comparably low for ISO.

tiroj commented 4 years ago

I'm having trouble understanding what the contention is here. There is an ISO standard—OFF—that can only be revised and updated using a formal process established by ISO that involves drafting of proposed change texts that then need to be submitted and ratified. It seems to me that no one is directly challenging that process or demanding that it be changed. Rather, what we're discussing is how to better manage collaboration on the drafting of proposals, on the work that is done prior to the formal process. And in that respect, frankly, anyone who wants to collaborate can determine among themselves how they want to collaborate, and if they want to use an email listserve, well, that's an odd choice given how much better suited to the task something like a git repo is and how much collaborative work has evolved since the 1990s, but, you know, have at. And if some other people want to use a git repo to collaborate on discussing and drafting proposals to then feed into the formal ISO process, they should just get on and do so.

@vlevantovsky created this repo, but as he says it is 'not established by ISO, it is not recognized by ISO', although it is owned by the MPEGGroup, which suggests some kind of affiliation with the organisation. If he's not happy with the repo being used to collaboratively draft proposed edits to OFF to be fed into the ISO process, let's go do it somewhere else. It all ends up in the same place, regardless.

vlevantovsky commented 4 years ago

@tiroj, this repo was setup as an issues-only repo to facilitate discussions, but you are absolutely right when you say

anyone who wants to collaborate can determine among themselves how they want to collaborate

I essentially said the same exact thing:

How we generate the proposals to make particular changes in a particular clause of the OFF standard is totally up to an individual (or a group of individuals) proposing the change, but in order to get it considered it needs to be submitted to the WG in a format they expect, and using the process they adopted.

tiroj commented 4 years ago

So, there's clearly a desire among some people to be able to use git versioning to actively collaborate on drafting texts as well as discussing issues. Ergo, the question is whether this repo should be allowed to become a non-issues-only repo for that purpose, or a different repo needs to be created? If the latter, who will host it, and under what administrative model and license?

vlevantovsky commented 4 years ago

the question is whether this repo should be allowed to become a non-issues-only repo for that purpose

This is something I cannot decide unilaterally, it may require consultation with SC29 and/or WG officials to get an answer.

davelab6 commented 4 years ago

@dwsinger said

@davelab6 you're arguing that more modern tools are better than email mailing lists. That is true, but not where we are, and a long way from where ISO is.

And earlier @vlevantovsky said

the mandate that establishes the AHG on Font Format prescribes us to use the email list hosted by AAT as our official communication channel (and not just us, all other AHGs established by MPEG Working Groups use the same AAT email lists server)

It seemed (past tense) to me that would only be true in so far as the mandate that establishes the AHG is in term. The mandate is renewed, and typically rolls over.

And it seemed (past tense) to me the next time the WG defines the mandate for the AHG, it can prescribe this GitHub repo instead of the AAT mailing list as the official communication channel, in the same way it was prescribed a YAHOO Group. There are other repos in this GitHub org, afterall.

But I take you both at your word that the MPEG SubCommittee 29 requires Working Groups who elect to establish AHGs to prescribe the AAT listserv as the only official forum for submissions. Fair enough!

But then if this repo has no official status, how is it bound by the ISO process requirements? It can then adopt a typical libre license to cover issue comments and files in the repo, and it can have files in the repo. Per the discussions above it probably also needs its own code of conduct...

behdad commented 4 years ago

But I take you both at your word that the MPEG SubCommittee 29 requires Working Groups who elect to establish AHGs to prescribe the AAT listserv as the only official forum for submissions. Fair enough!

No that's not true! Here, this article that Vlad has been using to pat himself on the back: https://blog.chiariglione.org/an-unexpected-mpeg-media-type-fonts/

Let me quote:

""" Not all technical communities are the same

A new problem arose, though. The overlap of the traditional MPEG membership with the OpenType community was minimal, save for Vladimir Levantovsky of Monotype who had brought the font compression and streaming proposal to MPEG. So a novel arrangement was devised. MPEG would create an ad hoc group that would do the work via online discussions, and once the group has reached a consensus, the result of the discussions, in the form of “report of the ad hoc group”, would be brought by Vladimir to MPEG. The report would be reviewed by the Systems group and the result integrated in the rest of MPEG work, as it is done with all other subgroups. The report would often be accompanied by additional material to produce draft standard that would be submitted by MPEG to National Body voting. Disposition of comments and the new version of the standard would be developed within the ad hoc group, and submitted to MPEG for action. This working method has been able to draw from the vast and dispersed community of language and font experts, who would never have been willing or able to attend physical meetings, to develop, maintain and extend standard for 16 years, and with outstanding results. MPEG has produced four editions of the standard called Open Font Format (OFF). As always, each edition of the standard has been updated by several amendments (extensions to the standard) before a new edition was created. """

So, Vlad keeps saying that "the AHG mandates this", while hiding from everyone that the AHG can be changed to be anything we want. The AHG is not official routine MPEG or ISO policy. Is a made-up thing FOR the OFF, with no process whatsoever. THAT's what I want to fix.

dwsinger commented 4 years ago

@davelab6

There are three significant problems that I see:

  1. ISO owns the copyright in the current spec. and does not permit it to be posted on the public internet (even though they make it freely available, I know). Yes, we could rewrite it from scratch, but...
  2. Yes, we could develop a new spec. using whatever process we like: but once it's been through the first round of balloting and comment, and adjusted by formal consensus of SC29 and the NBs that vote — it's no longer ours, and ISO doesn't permit DIS and FDIS to be posted on the public internet.
  3. ISO's current process is Microsoft-Word based; I have experimented with using markdown and bikeshed (I know it's a better method) but some things simply won't be in the ISO house style (notably references, but there are other problems). Whether we'd be able to continue using this development method is not at all assured.
davelab6 commented 4 years ago

So, there's clearly a desire among some people to be able to use git versioning to actively collaborate on drafting texts as well as discussing issues. Ergo, the question is whether this repo should be allowed to become a non-issues-only repo for that purpose, or a different repo needs to be created? If the latter, who will host it, and under what administrative model and license?

Some people want the w3c font-text group to charter a font format cg or wg and develop MOFF proposals there.

Lately I am trying to reaffirm the AHG as offering everything such a w3c group can offer.

But if the AHG can't be reformed, fair enough.

the question is whether this repo should be allowed to become a non-issues-only repo for that purpose

This is something I cannot decide unilaterally, it may require consultation with SC29 and/or WG officials to get an answer.

I thought this repo isn't recognized by them, so they have no concern? I'm genuinely confused.

davelab6 commented 4 years ago

@davelab6

There are three significant problems that I see:

  1. ISO owns the copyright in the current spec. and does not permit it to be posted on the public internet (even though they make it freely available, I know). Yes, we could rewrite it from scratch, but...

No hypothetical "could" about it :)

Simon is rewriting it from scratch already, and was told to put it under a standard body so others who are employed by companies with legal departments can allow them to contribute.

And Vlad has said he welcomes the effort to write a new edition.

  1. Yes, we could develop a new spec. using whatever process we like: but once it's been through the first round of balloting and comment, and adjusted by formal consensus of SC29 and the NBs that vote — it's no longer ours, and ISO doesn't permit DIS and FDIS to be posted on the public internet.

That all happens downstream. It's fine.

  1. ISO's current process is Microsoft-Word based; I have experimented with using markdown and bikeshed (I know it's a better method) but some things simply won't be in the ISO house style (notably references, but there are other problems). Whether we'd be able to continue using this development method is not at all assured.

If word is used to generate STS XML, we can skip it

If not, the current situation persists; we diff the current text with the new one and generate change proposals for the editor to copy and paste into word

behdad commented 4 years ago

I'll be discussing my issues live tomorrow: https://twitter.com/behdadesfahbod/status/1308566508226838528

Those asking for "evidence" can tune in to hear the full allegations first.

davelab6 commented 4 years ago

@vlevantovsky wrote,

making comments implying the invalidity or impropriety of officially established AHG communication channel is misleading and ill-advised!

I don't say the email list is invalid or improper. I say it's a technically bad choice, based on technical features and capabilities. I don't say it should be shut down.

I say it should be relegated to minor matters, in the same way the w3c font-text community group is prescribing GitHub for majority of matters and their mailing lists for administrivia.

I want the AHG to meet the members needs, to be "on par" with alternatives.

If this has to happen over a longer time frame, such as waiting for the next time the AHG is re-established, that would be fine.

If this really isn't possible, thats fine too. I can live with it. But I'm not sure how many people will be willing to, when there are greener pastures yonder.

behdad commented 4 years ago

If this has to happen over a longer time frame, such as waiting for the next time the AHG is re-established, that would be fine.

Which will be on October 12.

vlevantovsky commented 4 years ago

So, Vlad keeps saying that "the AHG mandates this", while hiding from everyone that the AHG can be changed to be anything we want.

Here you go again, you continue to make allegations that someone said something (with someone being me this time around), claiming that I said something, and this is demonstrably not true.

If you care to review the email list archive (you can search for "AHG kick-off" messages), you would see that AHG mandates change constantly, depending on the tasks we need to accomplish. What does not change though is our communication channel - there is a value in the continuity of the discussion and in having it open and accessible to all interested parties to join. We did use Yahoo Groups facility for over 15 years, and then switched to another provider when Yahoo Groups discontinued their services. The WG made a choice of another provider this time, choosing the organization who is an active, longtime participant in the work of SC29, and who has a long-standing record of serving the MPEG development community and all AHGs established by MPEG.