Building and extending trust

I don’t know that I criticized anything :slightly_smiling_face: I wanted to participate in this thread and brought a point of view different than the sentiments expressed above my own comment.

Re echo chambers: I was speaking metaphorically, no science there :smiley: you painted a picture, and I painted a different picture. My point was that a group in which ideas bounce off like an “echo” isn’t bad in itself. It can be bad, or it can be good. I don’t see it as a “systemic issue” that people generally tend to agree. The more relevant discussion would be the topic of their agreement. In this case, you could criticize something specific about Elm, the tool, or of some idea that’s settled amongst a group of Elm developers instead. This way I think you would get more constructive interactions on this thread :slight_smile:

Cheers.

I believe this is a misunderstanding of how the elm-explorations organization works, and what teams exist.

In your separation of A/B teams, the A team is literally just Evan.

There are people maintaining repos in the elm-explorations organization, who have access to kernel JS modules, but that access is not being used by those people to make interfaces for Web APIs.

From what I can gather, those repos mostly exist in elm-explorations to have access to some escape hatch:

  • elm-explorations/test uses JS for try…catch
  • elm-explorations/linear-algebra uses JS for fast math over Float64Arrays
  • elm-explorations/benchmark uses JS for high-precision timestamps
  • elm-explorations/webgl uses JS to interface with WebGL

To my knowledge it is not the case that there exist trusted contributors (members of the A team) who have access to kernel JS on any project they think of.

As an example, I’ve taken the maintainer role of elm-explorations/test after Max Goldstein. Do I have access to JS kernel modules outside that repo? No, I don’t.

TL;DR:
A team is comprised of one person: Evan
There might be an additional C team - maintainers of elm-explorations repos. Yes they can use kernel JS modules in those repos, but not outside. They’re also not tasked with making Elm APIs for Web APIs. In that sense they’re just like the rest of the community.

3 Likes

The difficulty with that way of thinking is that providing a default value is a valid way of dealing with an error in some situations; it isn’t always wrong. Dealing with errors is usually quite context sensitive - is it a bug (divide by zero)? is it a user error (invalid data entered)? is it a system error (out of disk space)? and so on. Without the context, how can a compiler know what is right?

Logging isn’t the answer either. In Java you frequently see:

catch (SomeException e) // Huff! Do I really have to?
{
    log.error("Something went wrong", e);
    // More usually its just
    // log.error(e);
    // because, you know, typing is hard work and so is thinking.
}

// Now I shall continue without addressing the error at all and with the program potentially
// in an unknown or unsafe state. Yay for the lazy devs! Sorry for the PITA bugs future
// maintainers...

Try downloading and starting up JBoss. The out of the box startup config will whizz about 5 or 10 stack traces past you as it starts up, even though it is working!

I’m happy to get more clarity on this, but cutting it down to two also wasn’t a matter of dividing by actual power in the organization. It’s also just trying to reflect what it appears like from the outside, because it’s really hard to tell who can do what when. So the fact that my description is inaccurate is hopefully just more proof that this could use more explanation.

That was literally the next sentence I wrote :smile:

It depends on what you’re trying to answer. I’m personally not looking for the language to give me bulletproof solutions in this case, since that has a lot of implications for complexity and development time. What I like about Elm is that it hits the sweet spot where for most code, I can be very confident it works, without requiring a huge effort. What I miss though, is the ability to tell if I’m right about it in production or not.

Hopefully the Elm community will abandon the official repos and infrastructure in the near future and a new era of iteration can begin. I read this recently and it gives me some hope for this path:

The community has already forked Elm anyway:

* The package site: elm.dmy.fr
* The package installer: elm-json
* The npm package: `@lydell/elm`
* `--optimize` mode: elm-optimize-level-2
* Parts of the runtime: elm-watch (“heavy” patching to support hot reload)
* Virtual DOM: elm-safe-virtual-dom (the infamous almost-vapor-ware) – my latest idea is to call it `elm-kernel` and replace all kernel code to fix bugs
* Core packages: elm-janitor
* elm-tooling-compiler and elm-dev are actual backwards-compatible forks of the compiler code
* Test runner: Has always been community controlled with buy-in from the compiler (`"test-dependencies"` ) somehow
4 Likes

Hey my friends, I’ve been reading these posts with interest. There have been a lot of valid comments here, from different perspectives.

I feel like I’d like to share a few nuggets of thought from my own experiences. I hope you don’t mind:

The purpose of a community is to move forward together

We commune so we can build a synergy that lets us accomplish much more together than we can on our own. This is usually around a central goal. Most of us feel more positive and trusting about our community when we solve problems or overcome obstacles together.

There is also an important, human need to commune. :slight_smile:

Open Communication Improves Our Successes

I love the ancient parable put to poetry by John Godfrey Saxe called The Blind Men And The Elephant. Lots to learn here. One of them is that different perspectives is a strength, not a weakness, as solutions to hard problems usually come from less-common perspectives. Another is that, at some point when conversation is not serving to move us forward, its OK to agree to disagree on certain points, so we can get to the next thing, which is…

The Best Way to Move Forward Is To Focus on What We Have In Common

I could go into a personal anecdote here, but I will save you the pain ;). Suffice it to say that many obstacles can be overcome by shifting perspective away from the obstacle, and focusing on where we can make progress, and usually the obstacle takes care of itself, at least, in time.

Another benefit to focusing on where progress is possible is…

Communal Trust Comes From Successfully Working Together

The best way to build trust is to build and overcome obstacles together. Bar none. I have gained a great deal of trust in this community over the past years because of all the successes and progress we’ve made in our ecosystem - AMAZING PROGRESS. :slight_smile:

An when there is trust…

Everyone Can Be A Leader

I have learned that where there is trust, more and more people in the community are willing to step up and lead out. And then we have more successes and so on and so on.

I have also learned that everyone can be a leader. Another way of saying the same thing is that everyone can lift where they stand. If you have the skill and/or are passionate about something, put it out there, talk with the community, and lead the way.

Cheers. Lets Keep Moving Forward. :slight_smile:

9 Likes

Hey @KasMA1990.

There’s an overwhelming amount of stuff going on here.

I can see there’s also some personal hurt here that some others resonate with too, which I’d like to acknowledge.

Taking action

I’ve re-read through this dialogue a few times trying to narrow down what the ask is, of who, and what I can do personally. After all, the only thing we can control is our own actions.

So I’m going to highlight parts of the dialogue where I felt there were requests that I could do something about, and went and did something about them.

That’s not to say I’m ignoring, disregarding or devaluing your other points, I simply just can’t address them all productively in this format, so I’m focusing on a subset to start.

On transparency

a key part of transparency is also that this information is easy to find, which I don’t think it is.

I think it would be a big improvement with a bit more formal structure, and better documentation of the way in which things work.

In part, you’ve described some of the reasons I started Elmcraft: to promote and facilitate the wealth of projects, initiatives, knowledge and people in the Elm community.

Elm Core Development process

With the help of @gampleman and some editing from @jfmengels and @wolfadex – I’ve just published a new Elmcraft page: Lore: Elm Core Development.

I believe this page speaks to the core of this particular thread’s dialogue and repetition in our community – and addresses most of the subsequent dialogue present here.

I would encourage anyone engaging in this dialogue to read it and think about where their place is in it, and think about where other folks’ place might be in it, and what you’re actually debating about – it’s very likely you’re debating differences in acceptance.

Community Lore

This document is part of an entirely new section, which I’ve named “Lore”. It’s purpose is to document the history and cultural knowledge in the Elm community to make it more accessible to newcomers.

I plan to announce & promote this in it’s own right more broadly shortly (so please give me time to get to that outside this thread), but in the meantime I think it is a start at improving transparency, and feedback/discussion is welcome – there are many more ideas that have been discussed over the last few years but not yet fleshed out.

On the A & B Team

As others have mentioned, there is no core team. And as you responded

the fact that my description is inaccurate is hopefully just more proof that this could use more explanation.

So I wrote another page: Lore: Elm Core Team, to make this more visible.

Where to from here

There’s a lot more here I would have liked to respond to (including other posters), but I feel it’s quickly becoming impossible to effectively address or even discuss everything raised in this linear format, let alone for others to engage meaningfully.

Leadership requires clarity of vision, and that’s hard to track here now.

Hopefully I have been able to (with the help of a few others) establish a small bit of trust by addressing directly some of the issues you’ve raised.

My hope is that with the added context and knowledge above, specific aspects of this dialogue can be refined or restarted to be less nebulous and more directed.

For example:

  • Now that there’s more clarity around “Elm core dev” and “Core team” – are some of your thoughts about what you think needs to change, or how it should change, different?
  • Can you now be clearer about what is directed at who. There’s a big mix of “Evan”, “Core team”, “Team A”, “we”, “they” etc. Which parts of your dialogue are asking who (Evan/the community/someone else) for what (empathy/action/engagement/activism/…), exactly? And what do you plan to do if that person/people aren’t willing or able to meet that request?
    • I.e. “I’m going to start a monthly forum where we will talk about the downsides of Elm for 1 hour, and work on making a list that we will publish to X with the goal of achieving Y” or whatever it may be.

I think it would be best to continue this dialogue in smaller more concrete pieces with this added clarity. Perhaps @KasMA1990 you’d be willing to summarise the various topics that you’ve opened that you still feel are still unresolved or warrant more discussion towards a particular outcome?


NB: If you (or anyone in this thread) thinks I’m drastically off-mark with something, feel free to DM me on Slack and clarify! I’m happy to have a quick back & forth to establish understanding or resolve confusion before further long cycle responses get added here, which will also ultimately make this dialogue clearer and more accessible for those following along.

18 Likes

Nice work. BTW I think the “no critical bugs or blockers” is my personal experience, others may have a different view - for example, the issues around 3rd party plugins messing with the DOM might be a blocker for some and the most obvious issue that comes to mind on this theme.

I wonder, is there an opportunity to propose fixes for this and get them into the next version? Say Evan puts out a 0.20 beta for evaluation and feedback, thats kind of our bug fixing window and the only one we may get for a long time.

Nice work. It’s encouraging to see multiple people collaborating on the documents.

For me personally, I have been hoping for the following to emerge over time:

  • Forking elm-lang.org with more content and details - I think a combination of elm-land and elmcraft cover this need for me. The only thing missing is to actually have elm-lang.org prominently link to these sites. (or even formally delegate management of the elm-lang.org to a marketing team)
  • elm-janitor keeps progressing and a few commercial users start adopting it and blogging about their adoption, and it eventually becomes the de facto release branch
  • More moderators and tagging / sections for this elm-lang discourse. I would really love if Mario, Simon, Rupert, or anybody who has been contributing/active for a few years to be added as additional moderators
  • Add one or two more people to the closed governance and maintenance of the core elm, just so there is always enough bandwidth to execute on the “batching” approach

Also, within the Elm Lore content, I don’t know if it is accurate to state that batching is the current approach to maintenance. I think that was happening in the past, but now it looks more like long exploratory phases, without any batching.


I understand the current general approach to maintenance, but I really relate to what Rupert has written in various threads - even if many of these bugs aren’t important, just having that communication and seeing your pull requests discussed and merged has amazing psychological effect of inclusion. I had made small PR’s to elixir’s documentation and they were rejected, but there was very quick discussion and explanation of what alternative would be pursued. I felt very included in the elixir community at that moment, as if I was a small part owner of the elixir core tooling. I understand that is a very draining exercise for the core team to interact with so many people, but it is really nice of them.


From a long term perspective, I have been very seriously mulling over the value proposition of isomorphic programming for web applications and I am drawn to liveview and nextjs within this category. If elm had a community style more similar to elixir, I would probably take a full stack project that comes out of elm very seriously (I like lamdera, but it’s outside of my interests), but right now, its hard to believe that enough developers would be drawn to back end elm to build out all the core building blocks (ORM, AWS bindings, various libraries) given the current community management approach.

If you are using this, please write about it and I’m happy to share in the newsletter!


I’m not sure I would call Elm Land a fork of anything Elm, but an Elm framework. Like NextJS is to Javascript, You wouldn’t call NextJS a fork of JS. Similarly I see elmcraft as more of a community driven group than an official Elm team.


I’m not sure this makes sense for Elm Land. Maybe for elmcraft as an additional community place under community? Not sure how @supermario would feel about this? I think it could be helpful. It could cause some fragmentation between users going to Discord instead of Slack, but that could also be beneficial in other ways.


What is the reason for more moderators? What type of tagging / sections do you feel are missing?


Evan covers these fairly well in his Strange Loop talk (not yet up on YouTube as of this posting).

Yes, that is how I would describe elm-janitor, although I do not think it should really ever become THE release branch.

What I described previously is that it should function more like a release branch than a fork - you make a release branch and patch bugs on it reported by the customer you released too. You also try and merge these bugs (and tests) back onto master. In some cases its not possible because master is changing and the fix is no longer applicable. The next release branch is taken from master.

Its never meant to “lead the way” on setting a direction for Elm - that would be a hard fork, at which time, it would be renamed to something more appropriate.

I do hope we can document succesful PRs and try to get them into the next Elm where they are still applicable.

I see your point, but I guess elm-land seems like such a natural place for beginners to start, that implementing an enhanced replica of guide.elm-lang.org inline in elm-land could be one potential next step to implementing a one stop beginner experience.

With nextjs, I don’t expect people learning javascript or React to start by reading the nextjs documentation. People might start with a video tutorial or reading a few blog posts or possibly jump into a book on javascript or React. Once languages reach a certain size, I think the actual homepage for the language becomes irrelevant and not many people visit it or know about it.

Thank you for the effort @supermario, you’ve done some great work there :blush: Getting a stricky thread going with links to what you’ve written (amongst other things) would help improve the situation a fair bit!

The truth is that there is no particular ask in my post. More than anything, I’m making observations and expressing my feelings. I’ve included some suggestions for how things might be different, partly because I know the community prefers actionable discussions over pure reflection, but I’m not asking anyone for concrete changes.

It’s analoguous to gathering feedback on an API change. I’m not asking for “the API” (that is, the community) to change in exactly one way or the other, but I’m stating the pain points I have with the way it works currently.

As this thread also illustrates, there’s a strong desire to “do”, sometimes at the expense of listening and understanding. But my main goal is really to build understanding of the importance of trust, and the ways in which we might be undermining it. Both as individuals and as a group.

You have!

That’s a good idea, there might be threads that are better picked up elsewhere. But I would also reiterate that I’m not trying to get particular solutions picked up from this. I see it as more important to understand the problem(s) as a whole. With such understanding, it might turn out that the problem is not worth addressing, or that there’s not much we can do about them without Evan being involved. Or maybe we can find small changes with large impacts that are actually within our control.

3 Likes

nothing bad about a new community around an elm fork. But where does the desire to “abandon the official repos” and the “hope” for such negative actions? :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.