How would a process for native Web APIs work?

[rupert]

So the subject of native code in 0.19 keeps being discussed, and recently a few new API suggestions have surfaced, such as Typed Arrays, a media API, file readers and a new low-level canvas API. People are keen to know how these will be developed under 0.19 with greater restrictions on native code. There have been some replies from prominent members of the community and some discussion around how a previous process for native code reviews worked and ultimately failed.

The answer to how it would work in 0.19 has mostly been along the lines of - there will be something but we don’t know what it is yet, its too early. But of course, nature abhors a vacuum so we keep asking.

I too am interested to know how we could have a process by which the remaining Web APIs not already implemented in Elm could be developed, and by which the power of this community could be harnessed to achieve that. I have something to share, but really want to hear other peoples ideas too. After all, we are not the first open source community, and our members will be members of other communities too, now or previously, so we all have experiences to share about what works and what does not.

What I wanted to share is the work of Pieter Hintjens who developed ZeroMQ. ZeroMQ was very successful and this was in no small part due to good community process. Hintjens thought about how to achieve this carefully, in a way that balanced the needs of everyone but was cleverly tilted towards maximising scale within a community.

Anyway, here it is, would love to hear your thoughts:

https://rfc.zeromq.org/spec:22/C4/
http://hintjens.com/blog:93

[pdamoc]

Anyway, here it is, would love to hear your thoughts:

Issue: Collective Code Construction Contract - C4.1

I would love to see a C4 style of development for elm-explorations or any kind of explicit process that would guide a person from needing an API to going through the design process for that API with other members to being accepted in elm-explorations.

[rupert]

Great minds think alike. High five @pdamoc.

[Dan_Abrams]

Thanks for starting this thread, Rupert. Some sort of process and information around this is my general impression of what’s needed, but didn’t really know where to begin.

[szabba]

Processes have overhead. The time and energy resources are limited. This is especially true for projects with small teams, like Elm.

Whatever changes in process happen will be a stepwise refinement of what’s in place now. A drastic change in process would be disruptive to whatever progress is being made. This would not be as much of a problem if the team grew bigger, but that would also take time and effort.

This ties into Evan’s often repeated point: copying what others are doing might not work in Elm’s context. Right now we have slow progress. Drastic process changes can have many outcomes:

• they break the project,
• they don’t break the project but there’s no improvement either,
• the project works better, but not as much as people wanted,
• the project works better and everybody’s happy.

Elm’s development has in a sense both low throughput (rare releases) and high latency (rare status updates). It is hard form me to imagine a process where Evan’s capacity to participate is not a limiting factor.

I get that people want to see a lot of things happen. I get impatient too. I think a lot of the time we might not be realistic about how much things can improve in what time frames though.

[rupert]

My question is “How would a process for native Web APIs work?” not “How would a process not work?”. Ok, you need a bit of that too to know what does work, but your comments @szabba are all on the negative side.

Does anyone here have experience with community processes for open source that do work? Could those be adapted to Elm? I am not suggesting that C4 be adopted unchanged, just that it provides some really good ideas and inspiration for how a productive process can be done. I will post some ideas in the next few days on the subject of how C4 could be adapted to suit Elm, which is of course different to ZeroMQ.

Processes have overhead. The time and energy resources are limited. This is especially true for projects with small teams, like Elm.

Interestingly, Hitjens wrote:

“What is most fun is that ZeroMQ takes zero management these days. It is self-steering, self-feeding, and self-organizing. We have applied C4.1 to old projects like libzmq, and brand new ones. The results are the same. If the project does something useful, it takes off, and contributors join, and everyone enjoys themselves.”

[evancz]

@szabba is 100% correct in their post. This cannot be a productive conversation for the reasons outlined there.

I’m gonna try to explain things further in a separate post before doing some additional moderation.

[evancz]