Proposal For J3 Committee Rules

[certik]

Problem

The J3 committee currently does not seem to have written down rules how it operates, how a proposal can be submitted (and what requirements it needs to satisfy), how and when it will be considered, and the committee currently does not provide official feedback why a proposal got rejected. Goals:

• Not waste precious committee time and not delay 202X standardization

• Respond to every proposal (currently the committee sometimes ignores a proposal)

• Get a wider community discussion around every proposal (currently the committee sometimes advances a proposal without proper discussion with the wider community or even the committee itself)

Proposal

I am attaching a proposal to improve how the J3 committee operates in order to make it a lot more efficient and achieve the above goals. At the same time the proposal is not radical and only requires a few small changes to how the committee operates and thus might have a good chance of actually being adopted.

committee_workflow.txt

I already discussed this proposal with about 7 people on the committee, and the feedback I am getting is either supportive, or a request for a wide discussion about this to see if we can arrive at a consensus.

[milancurcic]

Thanks Ondrej, I support this proposal. At this time I don't have anything to add to it, but I'd like to express a few observations and open-ended questions.

• As a Fortran application developer of 13 years, I found the committee quite removed and opaque, something between a benevolent mythical creature and an urban legend. Over the past few years, I've learned a lot from you, Steve, and few other members about how it works. Only recently I discovered that anybody can join the J3 mailing list, and I did. My point being, even though the J3 mailing list was publicly open, it wasn't obvious to me. It's possible that so many other people that would otherwise want to participate or just read aren't aware of it.
• Now that I understand better how it works, it makes sense why it's opaque and why the progress is so slow:
  • It's quite difficult to join -- be an alternate to an existing member, or pay membership to join as self.
  • It's also difficult to remain a member -- don't miss more than one meeting in a row. For many of us with busy schedules and/or lack of budget, it just doesn't work even if the good will is there.
  • Discussions via mailing lists and voting in meetings. This worked well a few decades ago, there are much better development models nowadays. This repo is a great example of one aspect of such development.
• I understand that the ultimate bottleneck is the number of compiler developers to implement features, however if the committee worked more openly and closer to the community, the community could grow and more compiler developers could join or come about by learning how to do it.
• Like @FortranFan likes to ask "for whom Fortran?", I think we should also ask "for whom the Fortran Standards Committee?". At a time when various flavors of FORTRAN were rampant in the wild, standardization made sense. I also understand that large enterprises put a lot of trust to something with an ISO stamp on it. However, does this model best serve the community, and even large enterprises nowadays? Should we look at some examples of productive language development teams like Python, Go, or Rust? Yes, they're backed by large corporations, but so is Fortran (Intel, Cray, IBM, NVIDIA etc.).

Anyhow, I ramble and don't mean to hi-jack the topic further. I didn't say anything that wasn't said before, but I think they're conversations we need to have. I'm beyond grateful for the committee's and compiler developers' hard work and the way Modern Fortran has evolved. Both my research and business are in large part thanks to it, and I'm sure I'll be a happy Fortranner for years to come. However, let's keep bringing up the conversation and reassessing the best way going forward.

If I'd pull out anything specific to this proposal, my recommendation for the committee would be to make it easier for people to participate, specifically:

• Lower the requirements for becoming a member and remove the requirement for physical attendance of meetings.
• Adopt a publicly open and online venue for language development. This repo is an essential step toward such venue.

[jacobwilliams]

A J3-hosted instance of Discourse (https://discourse.org) might be one option for an online venue for general discussion.

[certik]

@jacobwilliams Yes, that might also work: we could use Discourse for a general discussion, and this GitHub repository to keep track of technical issues for each proposal and to collaborate (using PRs) on new proposals (that was my original intention). In terms of priorities, this GitHub repository, while not perfect, does give us enough organization for now, and I think the highest priority is to set the J3 committee rules how it will consider the proposals that we can then start submitting.

[sblionel]

Many of the more annoying rules are forced on J3 by INCITS. (By the way, one can miss two meetings in a row before your membership is in jeopardy - you have to miss three in a row to lose membership, and attendance by any of your alternates counts.)

The J3 email list doesn't tend to get a lot of use between meetings, other than questions about what the standard says about some particular usage.

INCITS/ANSI/ISO have a lot of rules for how standards committees operate. J3 actually flouts some of them (for example, the J3 web site is technically not allowed) and we try to make things as easy as we can.

As for considering proposals, that's simple. Write and submit a paper, and you just need the template and get a J3 member to upload it when you have it done. All papers submitted are at least looked at at the next meeting (unless we overlook something, which happens but is rare.)

[certik]

All papers submitted are at least looked at at the next meeting (unless we overlook something, which happens but is rare.)

From my very short experience at the committee this is unfortunately not true. However, your word is enough for me and if you say that this is honestly just an oversight, then I believe it.

The confusion is out there unfortunately about this. See this recent question and the follow up discussion:

https://mailman.j3-fortran.org/pipermail/j3/2019-November/011732.html

---

As I said, your word is enough for me, that all we have to do is submit proposals. And so we will do that for the next meeting. We plan to submit 3 to 5 proposals for some of the highly requested features in this GitHub repository.

---

The main issue is however not resolved. We need to have written down rules how the committee operates. Does anyone have a link for the INCITS/ANSI/ISO rules for the J3 committee? I searched for them and couldn't find it.

[sblionel]

The rules are for all committees under INCITS (J3) and ISO (WG5).

http://www.incits.org/standards-information/policies

https://isotc.iso.org/livelink/livelink?func=ll&objId=4230450&objAction=browse&viewType=1

Happy reading!

[certik]

@sblionel thanks a lot! I am going to study this thoroughly before proposing how to move forward.