I just had an experience proposing some changes to the problem specs, where there was quite a bit of discussion and counter-suggestions and new suggestions for the same description file. In the end there was some confusion over where we landed.
It seems to be that GitHub’s newer code-review-during-PR workflow would be preferable in streamlining discussions when there are a lot of changes proposed at once for the same file. Maybe someone can confirm — I don’t believe it was that way yet when the “forum first” policy came into effect. Is it time to reconsider?
If not, no worries, I respect that, but in such cases, would it be possible to use a different external tool (e.g., Google Docs) to better organize comments and suggestions into threads? I know the forum is threaded, but not as easily and not by default (in terms of the view—collapsed by default).
Having a lot of proposed changes is part of the problem … if there are too many, it is very difficult to have a good discussion or review. So smaller blocks of changes are better.
The policy was less about the GH interface, and more about visibility across tracks and volunteers. Exercism has upwards of 400+ repos, and keeping track of all conversations across all of them is … a lot.
Rather than have things get ignored or have individual maintainers overwhelmed, the decision was made to have things discussed in the forum. Read here for more details.
This way, maintainers can cover for one another and also share the work of reviewing (and educating contributors). Its also very important for repos like problem specifications — because they are common problem definitions. So maintainers from different tracks have to agree to not step on one another. Here is an example of a discussion around updating a prob-specs exercise, proposed by a track maintainer.
I don’t think adding Google Docs to the mix would reduce chaos. In fact, I think adding another tool would make things much worse. But others can weigh in on that.
A comment showing the latest version of the proposed changes would help a lot, as it is very difficult to keep track of all the proposals on the forum, especially when there are many.
This is a decent question to periodically ask. On top of what @BethanyG mentioned, and what you point out, the structure here and the way tracks/repos are maintained has also changed.
Historically there has been a lot of… tension (!) on problem-specs, and thus you are experiencing organisation scar tissue. It’s great when an “outsider” (fresh eyes) looks at that and questions it, so please be persuaded to do that, as long as you (as you do know) realise there are likely reasons for it.
We can definitely meta-discuss how we could also make the process better if we decide to stick with forum-first policy?
Thanks for posting As DJ says, it’s good to periodically reconsider these elements.
Most decisions on Exercism are grounded in social reasons rather than technical ones. As a community we can pretty much make/solve anything using technical needs, but the human bit is much more messy.
As both Bethany explained and DJ alluded to, there’s a lot of complexity around having lots of people from different cultures, backgrounds, timezones, and commitment-levels somehow working together in ways that function productively and calmly. And as Bethany also mentions, 400+ repos means that things like GH notifications are often a graveyard. I regularly have 1000+ unread notifications on GH, because there’s so many different types of thing that I get pinged for. I’m sure others are similar.
GH also very much lends itself to discussing code. But very rarely are the conversations about code. They’re normally about ideas. What the forum does is gives us a human-centric space where we can discuss things at a higher level away from the code. Therefore the normal process I advocate for is:
Make human level decisions in the forum. Do we want to change X? Is there consensus about it? How do we want to change it? What are the general tradeoffs? How might it affect students? etc.
Once we have a very clear consensus, move to the implementation of that decision in a PR. This is where we can refine the smaller details, and normally that PR only then needs to be touched by a couple of people, because the wider community have agreed the intention of the PR. Whether the wording is perfect or not is normally something that matters less at a consensus-level than whether we should do the thing in the first place.
There’s normally a reasonable inflection point where the conversation shifts from (1) → (2). Normally I see new contributors want to get to (2) faster, because they feel like they want it done, but what they don’t realise is that if (1) isn’t done well, (2) normally really hard-stalls at some point. So investing more into (1) and getting stuff really clear there, tends to make (2) much more seamless.
With all that context, if you do have any thoughts on how we could make things better, either through process or guidance we could provide, I’d be very open to exploring it
Thank you one and all for your thoughts and insights here.
I can see that I need to focus changesets a bit more. In this case there seemed to be a lot of “while we’re at it…” additions, but if I had a clearer purpose for each thing in the first place, maybe it could’ve been avoided — and that’s something that anyone involved in the discussion can help with, which is empowering. I’m glad there was a link to another discussion — I see another valuable technique (especially once a conversation or changeset has snowballed) is to still do commits, but not PRs, in order to link more easily to the proposed diffs.
As DJ says, it’s good to periodically reconsider these elements.