Can we make forum discussions lead to action?

[bruce-wayne]

I’ve noticed that a lot of good discussions here eventually just… fade away. Someone shares an idea, people chime in, there’s even some agreement — and then the thread disappears into the depths of the forum without anything actually happening.

As an example, here are two threads I started that reached consensus that something should change, but then we lost track of any real follow-up.

Interest is Interesting: Test violates problem description

0.5% for a positive balance less than 1000 dollars. public void Minimal_first_interest_rate() { Assert.Equal(0.5f, SavingsAccount.InterestRate(0m)); } 0 is not a positive number. Interest rate for zero balance has not been defined.

Word Search test cases are ambiguous

Given the puzzle: []string{"jefblpepre", "tclojurerm"} and the word list: []string{"clojure"} the test suite expects the output: [[1 1] [7 1]] However, my implementation finds: [[1 1] [6 0]] Both paths are valid — the difference can be seen here: [Screenshot 2025-10-22 at 11.51.58 PM] I can’t figure out what distinguishes one path from the other. There are several test cases in this exercise that are similarly ambiguous, where multiple valid answers exist but only one is accepted. I…

It’d be awesome if we could make discussions a bit more action-oriented. Once there’s a clear takeaway or agreement, maybe that should trigger something concrete — for example:

• Open a GitHub issue to track it, and post the link to it in the forum thread.
• Summarize the outcome and tag it as “ready for action” (or similar).
• Or just have someone say “I’ll take this on!” so it doesn’t get lost.

Basically: once a post reaches some kind of consensus, it should lead somewhere. Otherwise, a lot of good ideas risk disappearing.

What do you all think?

[IsaacG]

Who is the “we” in “Can we make … action?”

Welcome to the open source community. Often if you want to see change happen, you need to make it happen. Exercism has a staff of two people, one of whom focuses primarily on the front end and the other who is neck deep in a complicated weeks/months long project. Most of the track contents is managed by volunteers and members of the open source community.

Or just have someone say “I’ll take this on!” so it doesn’t get lost.

This is usually how (non-track-specific) change happens: someone takes it on and makes it happen. That role typically falls to the person that started the discussion.

Change requires someone to own the change and make it happen. I noticed both of those linked threads are opened by you ;) You can definitely stay on top of the discussions you opened and keep them moving towards a resolution!

One of those linked threads is only actionable by the track maintainer. Tracks and run and managed by maintainers. Changes require the maintainer involvement. If a maintainer doesn’t get involved in an issue, it’s hard to get them to move.

The other thread has some movement towards an updates problem spec description. The thread has meandered a bit. You could nudge it towards a resolution by summarizing the desired change, ie the concrete and specific proposed new documentation. If there is a concrete and specific proposal, maintainers can weigh in on it. If three maintainers agree it’s a good change, you can open a PR to make that change happen.

[keiraville]

The consensus with “Interest is Interesting” is that any change would be at the discretion of the track maintainer(s).

With cross-track problem specifications like Word Search, proposed wording is turned into a PR when three maintainers support the change.

[mk-mxp]

Sometimes it requires a bit of patience, too. Open source communities tend to require more time for a single action but do a lot in parallel. After all, declaring a thread “stalled” is based on a personal feeling of “this is forgotten” and not on a forum bot marking it “closed to inactivity”.

I think waiting a week or two for a maintainer reaction is not too long. But I also tend to ping them again after, say, a week to make sure they don’t miss to react.

Also, somehow some people are good at creating community momentum and others (including me) are not. That also changes the amount of action resulting from a discussion. Open source contribution much more is a social skil than other programming “jobs”.

[SleeplessByte]

Id also like to point out that we are actually not change-averse and willing to listen.

If you propose a change with decent reasoning, there is a high chance of that that will be accepted.

What we (as a community) can do better is to let newer people like yourself know what the potential outcomes are and how to reach them.

[oxe-b]

It is usually expected that the OP coordinate the action, proposing a change, discussing it and, once it has enough approval, making a PR.

[bruce-wayne]

expected that the OP … making a PR.

I tried that approach previously but encountered some pushback. Since there wasn’t any indication that the outcome would be different this time, I decided not to pursue it again.

Meetup PR was auto-closed

[oxe-b]

You shouldn’t start with a PR without getting approval first. But if you propose a change and it is accepted, it is usually expected that you make the PR.

But I agree with SleeplessByte that this is not as obvious as it should.

[IsaacG]

PRs are totally welcome … but generally only after getting approval on the forum for the PR to be created. Track-specific changes should be signed off by a track maintainer prior to having a PR created. Problem spec changes should be signed off by three maintainers prior to being created. Website PRs should not be created.