[NOTICE] This repo is temporarily only accepting bug-fixes. #1560
Comments
I want to second this. We are absolutely open to the tracks evolving! Once we have a better handle on the product side of this, we can start working on generalizing any of the experiments that end up in individual tracks. Of course: if there's an exercise that goes into one track, there's no reason why maintainers can't collaborate to put the exercise in multiple repos, but still at a track-specific level. ❤️ Thanks @iHiD |
As I have noticed that PRs have started rolling in again (hooray), and that all these could be placed in the categories allowed in the above sentence, I assume that the problem-specifications repo is still in a state of emergency, but that some contributors increasingly send in improvements.
I think a status update is due soon, as it's been 11 weeks since this statement was made. I have some points that I'd like to make about organizing and voluntary work, but I'm unsure where to place them as I don't want to turn this notice into a discussion for which it was not intended. Perhaps, as part of making a status update you could also provide a place for a discussion. I think having one will show the amount of good will even among people who have disagreed about particulars. |
|
Thanks @sshine. We're aiming to release an update this week on how we're planning on evolving tracks in general terms, and a project we'll be launching to address many of the problems that have emerged. |
|
Is there any indication yet for when this repo might accept exercises again? |
|
I think it would be best if this repo was reopened for adding exercises, and introduce a mediator policy for when discussions get out of hand. While any of this work may lead to exercises that will be ditched down the line because the research project rethinks core tracks entirely, we lose a lot more than a couple of exercises by removing a hub for cooperating and communicating across the project, which this repo is. Not doing so undermines the decentralized / federal structure that makes out most of Exercism. TL;DR: I'd rather add new exercises and lose them later, than see cooperation whither. |
|
For those that missed it, I talked a little about our plans for tracks in this blog post last week. As part of that we are going to be defining core exercises that have much more defined rules about what they should be and how they work across multiple tracks. We need to do a chunk of work to understand that before we can accept core exercises. I imagine we'll allow new side-exercises a lot sooner, but there are still questions that need answering about how things work across tracks before we do that too. So in the interim, I'd suggest just adding exercises to your specific track(s) rather than here. |
While I agree with this in principle, there are fundamental problems over how exercises should be structured in this repo to work across multiple tracks, and every discussion results in the same debates. This itself has been extremely detrimental to Exercism and seen people leave as a result. So I'm not sure that reopening this until we have those answers will help Exercism, rather than harm it more. |
|
Since Belgium went without an elected government for 589 days, I'm sure we could wait a little longer for this repo to come back into a fully functioning state. :-) |
|
@sshine So far it's been 973 days since Northern Ireland had one. But I'm not sure if that they would be considered to be OK given the Brexit milieu... 🤔 @iHiD I don't mind if the repo is closed for new exercises, but the period of closure should probably not be open ended. For me this latter is what would kill off community involvement in a project. Is there an estimate, or hoped for timeline for the "chunk of work" you mention? |
So, this is something that confuses me a little, and therefore I feel like there's something I'm unaware of. A couple of people have said similar now. From my POV, while I understand this repo is a central hub for discussing exercises, it's not intended to be a central hub for the community or for general discussion of Exercism. Either Slack or exercism/exercism (probably triaged to exercism/discussions) are what are intended for that. And also discussion on all the individual tracks (although I understand some might be lonely). If problem-specs represents something greater than the architectural "home of exercises", I would appreciate being told more about this so I can ensure that we don't lose something valuable by this delay.
In my head, there are two things to:
|
From my perspective: The exercises are one of the defining things of Exercism. Changes to them affect pretty much everything else that Exercism offers: what students can learn, what mentors can discuss with them, what common issues students and mentors encounter etc. So while it might be "just" the architectural home of exercises, every major¹ discussion here is also a general discussion about what Exercism is or should be. This repo is probably the place where the community can have the biggest direct impact/influence on Exercism as a whole, simply because exercises play such an important role. ¹ a small bugfix or rephrasing an exercise description probably doesn't fall under this but I think you know what kind of discussions I'm referring to. |
|
@SaschaMann Thats helpful. Thank you. And I agree.
And this is why there's so much passion in the discussions, because each affects both Exercism and all the tracks. The key thing in all this is that we have the situation now where a change to an exercise can wreck someone else's work on the anatomy of their track (e.g. the exercise becomes too easy or hard for the point it's been designed for). Or a change can mean that the automatic-analysers that someone else has written no longer work, or give feedback that's wrong, totally confusing the student. These problems/situations didn't exist 12 months ago, because effectively Exercism was buckets of exercises grouped by language. But as we things have got more complicated, maintainer's needs for stability in exercises have changed, and so we need to work out this repo can work in a world where change is very risky. And this also makes people really passionate about each PR or issue in this repo, because the consequences to their tracks can be really dramatic. So we need to find a way to keep contribution to this repo (and exercism) fun and painfree, while being aware that changes have really big effects across the site and infrastructure. And I think the only way to achieve that is with good guidelines and tooling. And to be clear, we'll come up with those guidelines and that tooling with the maintainers, but it's clear from recent discussions that there does need to be some leadership here in order to find a solution that considers the big picture of where Exercism is going along with the various (extremely valid!) opinions everyone holds and have been passionately explaining. |
I can clarify that I meant this specifically in regards to this repository. However, the track repos do have some level of dependency upon this one (I don't envy the job of reconciling the tracks' new non-canonical exercises when this repo does start accepting exercises again 😬 ). To get to why I feel like an open ended closure (I guess we have a ballpark of 12 months based on the blog post?) would be bad in general, is that it gives no indication to potential contributors of when they should return, or how to gauge the status of things. Imagine the following scenario:
What would you do as the new contributor in this scenario? Honestly, if it were me I would view the thing like a ghost project and take my enthusiasm elsewhere. Not trying to nail folks to a board on this, or change the priority over other things you may currently find more important. I'd just like to understand if there is an estimated timeline so I know when to come back and help out again on this particular front 😃 |
|
@wolf99 Thanks. That's very helpful. So a couple of points to pull out.
I tried to give a little bit of a timeline things in my comment above. Before Christmas time for "core" exercises - and I expect these to probably be substantially different from current exercises. And I'd like us to start discussions with the maintainers about how we can continue to grow our "side" exercises once Katrina and I have had some time to discuss. I hope this later part will be in the next few weeks - but at the latest Halloween, when we're physically meeting to work on things.
So this is probably the key different in my perspective. The route I see for most contributions is people using Exercism, becoming a mentor, joining Slack, and chatting there. Things are pretty active there, and we have ~3 new people every day sign up there looking to help. So for me, the entry point tends to be becoming a mentor and then getting more deeply involved through that. I don't think many people would look here as the first port of call, but maybe I need to update the OP of this issue to clarify that people should reach out on github.com/exercism/exercism if they get want to help but don't know where to start, etc.
I think there's another interesting dynamic here, which is things are really active in other areas of maintenance. We have ~15 or so Analyzers being developed and a similar amount of test runners, as well as a whole load of mentoring notes, so these are the main areas where people are heavily contributing to developing Exercism right now, and I think most maintainers already feel quite overwhelmed with all of that side of things, so their focus isn't really on adding new exercises etc, which is why pausing this for a while has felt ok to me. But I understand that for lots of other maintainers (especially on newer tracks) growth is important, and you're right to ensure that this to become a barrier for those people.
I really appreciate you driving us to clarify things here and also that you're probably representing lots of peoples views who I don't know about or understand here, so please bang the drum as much as you feel necessary until you've got satisfactory answers :) |
That sure isn’t the route I’ve taken (granted, I’m only one data point). I use Exercism as a student and then joined the GitHub org to contribute some exercises in obscure languages. I think I’m on the mentor list too, but I’m barely aware that the Slack chat even exists—I’ve certainly never used it. Slack is probably very useful for the core team, but it’s not a good medium for folks like me who contribute to a project sporadically and at odd hours. So for me, for all practical purposes, the Exercism project is the website/CLI and the GitHub repos, and so I have to agree with @wolf99 that it’s disconcerting to me to have one of the central repos locked on a “semi-indefinite” basis. |
|
As you pointed out, @iHiD, exercism/exercism or exercism/discussions are alternatives, but the reasons I don't post there are:
Wrt. Slack:
If Exercism were a town, exercism/exercism would be the town square with nutters, traffic and loud noises, exercism/discussions would be the agenda'ed town meetings, and the tracks would be all the places in the town that are actually useful to visit. And for all the town hall workers, they're delegated to the town square while their offices are being renovated. Also, Slack is the McDonald's: They have tables, chairs and wifi, so surely it's like an office. You just have to buy something if you have to use the restroom. ;-D @iHiD: I do, however, agree with your temporary lockdown: There's a structural problem that needs a lot of concentrated brainpower thrown at, and a dedicated research/working group does not sound bad at all. But the self-governance of discussing and approving PRs, brainstorming new exercises and even the failed attempts to tackle these structural problems, is something I'll miss as long as it's not here. Aaand... sorry for wall of texting! |
|
I submit that it is time to close this issue and return to normal operations in this repo. Shutting down this repo for contributions has been an impediment to contributor morale in particular and to enthusiasm for Exercism in general.
It's been 10 months with no substantive information about how this issue is progressing. The natural suspicion is that it is not progressing at all. We know how v3 should work; progress is being made there. Concept exercises are shared to the degree possible, but in many instances are necessarily track-specific. Practice exercises, however, are still a natural target for standardization via this repo. Are there actually any remaining pending questions which need to be answered? If yes, the core team should make answering them a priority; it does nobody any good to adapt to a permanent state of emergency. If no, then there's no reason to keep this repo locked down. |
|
Another option is to close this repository and mark it as archived and create another repository with another mode of governance that is not victim to the two main problems of "too many chefs with veto power" and "if people disagree too much, nobody gets to cooperate." If track maintainers are left to their own devices anyway, there is no reason why cooperation should not happen on any premise any subset of people agree to. So I posit that anyone who cares enough can simply create another repository and collect exercise templates in whichever way they like, and start accepting changes under some set of principles. This would leave room for the incremental improvement of what practice exercises exists in a track, compared to the top-down redesign approach of v3 concept exercises. Surely both efforts can coexist? Kindly, |
Another option would be that the exercise author (or their language team) would become code owner of that exercise and have the final say on changes to it. It would be quite hard to do retroactively but at least it would unblock new exercises from being added to problem-specs. (This might be better in a different issue) |
|
tl;dr Thank you for your thoughts, but I don't think anything has changed that would solve the problems that caused this in the first place. and the slow progress in many tracks for v3 makes me extremely reluctant to want to split focus even more. Once we get closer to the launch of v3 we can solve this problem.
As nothing has changed other than a few of the contributors who were frustrated having now given up and left, I don't feel like there is any change that would indicate this issue should change.
Yes. All the original questions.
I don't think this is more of a priority than our work on launching v3, which in itself removes many of the problems that this repo faces (e.g. no exercises here will be Core Exercises, which is where a lot of at least one of the major problematic areas is founded).
We have a Exercism-wide project that is desperate for contributors creating exercises, which needs as much focus and energy given to it as possible. If people have exercises to contribute, then there are dozens of tracks hoping to have exercises written. There is huge value in one Concept Exercise right now, there is little comparable value in one extra Practice Exercise. I don't see any logic in splitting people's focus or energy further. Right now Exercism needs people to do something specific. If you want to help Exercism then the way to do it is to invest time into making Concept Exercises. Once we have got over that line, things can return into a more "maintenance" state as things were before. Until that point we need focused contributions in v3. If people feel like this repo is more important than preparing for v3, then I've clearly not communicated something well enough. @SaschaMann That was vaguely the idea that Erik and I came up with when we spent a day in person focussed on this, but its fraught with complexities. @sshine I've also thought about something similar, although with forks at the exercise level not the repo level. Maybe forks of exercises (that are maintained in here) and tracks choosing the fork they want.
Not really. As one takes away from the other. And we're desperate for people to contribute to v3. Sidebar: I don't think v3 is any more top-down. Tracks can create whatever exercises they like - those are not dictated to them. We just have a spec that needs conforming too that's different and more involved than the simpler Concept Exercise spec. To everyone: I'm not going to shift on this for now, so please let's not debate it. I'd appreciate that. I have zero spare energy to try and solve the problems in this repo and am not going to make fundamental changes to how it works without significant thought. Once we get to a point where maintainers have momentum on creating v3 exercises, I'll be able to shift my energy back to things like this - but for now all my time is used trying to make the contribution process easier, so that we can get those tracks on track (excuse the pun). |
I was not trying to convince you of anything. With what wording we choose to label a repository as closed, perhaps the difference is small.
If Exercism v2 and v3 were the only two things in the world, yes. I don't have time for v3, since it involves curriculum design. I do have time for v2, since it involves tweaking what we have. I hope you find enough resources to progress with v3 for some high-traffic tracks to justify discouraging cooperating on Practice Exercises, since this is a big driver for the organic growth of contributors. Perhaps v3 just as much, but I wouldn't know.
My proposal wasn't that you should try to solve the problems in this repository. My proposal was that someone else should try and solve similar problems outside of it. This is the power of open source and decentralized version control. |
It doesn't. This where so many tracks are getting unstuck. There are lots of exercises ready to be ported to all languages on a range of topics. Tracks shouldn't be trying to design everything up front as it's a huge painful job. Instead they can just start chipping away at adding Concept Exercises.
There is nothing stopping anyone from continuing working on their v2 tracks. Lots of people have continued to do that, and that does not rely on this repository accepting new content. This repository simply simplifies that. If you want to keep improving a track, that's brilliant, but I don't want to have to moderate large-scale debates here, which is where this repo got to. So for now, that's on pause.
I know. But there are many people who will read this thread and have strong opinions, and I don't want to spend a day debating it, so I was letting people know that it wasn't worth their time trying to have that discussion at this time. Simon, it's great that you and others want to push forward with improving the existing tracks. It's a shame the discussions in this repo got to the point where I had to pause this - I didn't do that lightly and the decision came out of what was happening (e.g. maintainers quitting over the debates here), not out of some pre-conceived idea that I had. We will get this repo open again in some form. In the meantime if you want to keep improving the existing exercises in your track repo, that's awesome, and if you want to port some exercises to your tracks for v3 (or if you have time add some new ones, which we're trying to make a very quick and easy process) then that's great too. All of those things are hugely appreciated. |
(We've been pushing small fixes like these directly to javascript and typescript and I recommend everyone to do the same 🙂 If it's broken/can be improved for your track, do it! 😄) |
This was not an initiation from my side into a discussion of what I think is difficult about v3; it was an argument against saying "one takes away from the other" using myself as an example, so disregard my particular argument; it could have been any reason. I think this statement is not true, and so is not warranted as an argument in the present context. I should have added more explicit quantification; since, for me, it involves curriculum design. I understand the choices that were made, and I think it has a great additive effect across tracks that are alike. Besides curriculum translation across paradigms and idioms being difficult, adding some fun exercise that appears marginally better than some existing exercise, is easy, for me. I won't take more of your time as I think that is only reasonable to the extent that one contributes. :) |
|
Those of you who are passionate about us getting this repo back open ASAP but don't attend the video calls will be interesting in the discussion of problem-specs we had this week: https://youtu.be/IiUGMzaUNKQ Conversation on problem-specs starts at around 39mins in. |
|
We're in the process of re-opening the Problem Specifications repo: #1674 |
|
This repo is now reopened. Thank you all for your patience. Details at #1686 |
* resistor-color-duo: add test case to ignore additional colors (exercism#1569) resistor-color-duo: ignore additional colors * [Space Age] Put Earth in it's proper order - Move Earth into its proper position in the solar system - Make wording more consistent * Remove commas from seconds amount Co-Authored-By: Victor Goff <[email protected]> * Add data structures to topic list We have a number of exercises that are about data structures, but the topic was missing. * Scrabble is a trademark name. It should be capitalized. It is also a noun, meaning a "doodle", and a verb, such as what this description could be considered. In our case, we are referring to the trademarked name of the game Scrabble. Signed-off-by: Victor Goff <[email protected]> * Add testcase * Matrix: Add symmetric test cases for non-square matrices * matrix: fix whitespace issue (exercism#1578) * matrix: fix whitespace issue Fix whitespace issue introduced by exercism#1576, closes $1577. * Matrix: bump version number. * leap: Add years that refute some unusual factors (exercism#1581) leap 1.6.0 Some implementations unexpectedly pass the entire test suite: * Replacing 4 with 499, 998, or 1996 * Replacing 100 with 5, 10, or 20 * Replacing 100 with 3, 6, 12, 15, 30, 60, 75, 150, 300 * Replacing 400 with 125, 250, 500, 1000, or 2000 Adding these test cases would correctly point out that these solutions are incorrect. I think it's a bit unusual since no student is going to write such an implementation except a student deliberately trying to slip past the tests. Or maybe a student trying to micro-optimise? Maybe they are trying to test whether division by small numbers is faster than division by large numbers? But discussion participants have deemed that the cost of three tests is worth the benefit of reducing mental overhead of mentors, since such solutions have in fact been seen in the wild. * Add micro-blog exercise (exercism#1509) * Add micro-blog exercise This is an exercise requiring students to truncate unicode strings. Solves exercism#1507 * Micro-blog: Don't assume native English speaker Thank you @SaschaMann for the feedback and suggestion. exercism#1509 (comment) > I don't like that this assumes the perspective of a native English > speaker. English is a foreign language to most of the world. Perhaps > something along the lines of "text in most of the world's languages and > scripts" would be a better description. * Micro-blog: Add tests for different languages Feedback from @SaschaMann exercism#1509 (comment) > I think it would be nice to add some test cases that aren't emoji or > English - perhaps cases with germanic umlauts, cyrillic and/or greek > letters, historic scripts etc. - because that's one of the main uses > and goals of unicode. I've added German, Bulgarian, and Greek examples. All of them have non-English characters. None of these characters use multiple UTF-16 codepoints. As such, if you use a UTF-8 programming language you may first have trouble with the German example, but if you use a UTF-16 language you will probably first have trouble at the Emoji example. I chose not to add an example with historic scripts, because I'm not aware of any that display nicely in my terminal or text-editor. Perhaps in future some could be added. I wanted another example that would be problematic in UTF-16, so I added a poker hand example using playing cards. * Micro-blog: Add German truncated example Comically, it goes from "bear carpet" to "beards". @SaschaMann, thank you for finding the example for me: exercism#1509 (comment) * Micro-blog: Add longer maths example Empty set is a proper subset of the natural numbers which is a proper subset of the integers, which is a proper subset of the rational numbers which is a proper subset of the reals which is a proper subset of the complex numbers. It remains true when truncated which is quite nice * paasio: Title as "PaaS I/O" instead of default "Paasio" (exercism#1589) Improves the copy only, so acceptable in light of exercism#1560. * Fix broken link to website contributing document * topics: add 'pointers' in section 'data types' * robot-name description: singular "robot" Use singular forms consistently throughout robot-name/description.md * connect: Replaced rhombus with parallelogram Replaced "rhombus" with "parallelogram" to clarify that the game's board height and width must not be the same. Closes exercism#1597 * minesweeper: remove border (exercism#1602) * minesweeper: remove border Updates the board example to remove the need for a border that doesn't match the test data and clarifies a couple small points. * minesweeper: fix characters Mispelled "asterisk" and didn't use the same character as `diamond` for the blank spaces. * minesweeper: use mine counts Updates "score totals" -> "mine counts". * list-ops: change order in append test case description (exercism#1611) * Change order in append test case description * Bump patch number * isbin-verifier: add EOF newline (exercism#1616) This fix the issue that `configlet generate .` is not idempotent as the track's README might manually adjust for the newline instead. This is something I came across while working on exercism/julia#161. * exercism#1623 `grade-school` canonical data does not correspond to the exercise description (exercism#1624) - case description is altered according to the discussion results - patch version of the canonical-data is updated * fix: Remove trailing spaces I have confirmed that no JSON version change is needed * Bob: Cleans up language on a couple of test cases Resolves exercism#1630 * Bob: Replaces DMV with dentist (exercism#1632) Resolves exercism#1630 Replaces ambiguous `DMV` with `dentist` and `NASA`. Co-authored-by: Peter Goodspeed-Niklaus <[email protected]> * luhn: check a number with an even remainder (exercism#1635) * test(luhn): check a long number with an even remainder * fix(luhn): minor version bump instead of a patch * [two-bucket] Make valid moves clearer (exercism#1644) There has been confusion over the reuse of the word "one" in both the descriptions of the bucket ("Bucket one") and the moves ("Move from one bucket"). This removes that confusion, which will help reduce misunderstanding, especially amongst non-native English speakers. * scale-generator: fix name of augmented interval (exercism#1643) The interval described is an augmented *second*, not an augmented first. Added also its composition in terms of steps for completeness. Fixes exercism#1642 Signed-off-by: Rafael Fonseca <[email protected]> * Add requirements of the exercise (exercism#1645) * two-fer: Update description.md (exercism#1583) * Update description.md I don't think it's great anyways but I'm tired of seeing students submit X as the variable name because of picking up some subliminal hint here. * Update exercises/two-fer/description.md Co-Authored-By: Victor Goff <[email protected]> Co-authored-by: Victor Goff <[email protected]> * Update Simple Linked List metadata (exercism#1648) Previous link was no longer working properly, so use web.archive.org need this before merging exercism/rust#935 * Fix metadata source_url for simple-linked-list exercise (exercism#1649) Previous web.archive.org link pointed to the book homepage. Change it to point to simple-linked-list page. * Fix apophenia error slowing student progress (exercism#1650) * Fix apophenia error slowing student progress apophenia - noun "the tendency to perceive a connection or meaningful pattern between unrelated or random things" compare: pareidolia - noun "to perceive a specific, often meaningful image in a random or ambiguous visual pattern" - Merriam Webster's * Fix premature doubling in 1st example for Luhn * Update description.md (exercism#1653) The test suite is testing against the key having only lowercase letters, not alphanumeric. * two tests to check case insensitive behavior (exercism#1658) * Revert "two tests to check case insensitive behavior (exercism#1658)" (exercism#1659) This reverts commit ea9db9b. * Palindrome Products: refine the problem (exercism#1662) For me it took a while to understand that we calculate product of exactly two numbers. BTW in the [original problem](https://projecteuler.net/problem=4) it is stated clearly. * robot-name: remove dead link (exercism#1663) gSchool.it is now a domain parking spot * Add uuid field to all test cases (exercism#1676) * Add uuid field to documentation * Update canonical schema * Add uuid field to test cases * Update canonical-schema.json Co-authored-by: Sascha Mann <[email protected]> * Update comments in README * Remove version check Co-authored-by: Sascha Mann <[email protected]> * Remove version (exercism#1678) * Replace optional key with scenarios (exercism#1677) * Replace optional key with scenarios Co-authored-by: Victor Goff <[email protected]> * Add GH Actions CI workflow (exercism#1680) * Add GH Actions CI workflow * install yarn dependencies * fix node-version field * Remove check_optional Co-authored-by: Jeremy Walker <[email protected]> * cache yarn dependencies * use node 12 * remove Travis CI config * Update .github/workflows/ci.yml Co-authored-by: Sascha Mann <[email protected]> Co-authored-by: Jeremy Walker <[email protected]> Co-authored-by: Sascha Mann <[email protected]> * Add description of tests.toml (exercism#1682) * Add description of tests.toml * Update CONTRIBUTING.md Co-authored-by: Jeremy Walker <[email protected]> Co-authored-by: Jeremy Walker <[email protected]> * Add scenarios to example and describe purpose (exercism#1683) * CI: Clean up workflow and clarify what "JS tests" are (exercism#1697) * Move required files check to separate job * Clarify what JS tests are * Rename schema-tests to schema-validation * CI: Add codeowners (exercism#1699) * CI: Add codeowners * Update .github/CODEOWNERS Co-authored-by: Jeremy Walker <[email protected]> Co-authored-by: Jeremy Walker <[email protected]> * Add reimplements to schema (exercism#1703) * Add reimplements to schema * Fix formatting * list-ops: add append case (exercism#1612) * Add case to append empty list to list * Add UUID Co-authored-by: wolf99 <[email protected]> * resistor-color/resistor-color-duo: extend exercise explanation (partial copy from resistor-color-duo) (exercism#1667) * CI: Check that UUIDs are unique (exercism#1700) * diffie-hellman: Reword 'in range 1 .. p' (exercism#1688) There are some languages where the syntax `1 .. p` includes both the endpoints. For example, the Nim code: ``` for i in 1 .. 3: echo i ``` shows the output: ``` 1 2 3 ``` So let's prefer the wording from the `description.md`: "Alice picks a private key, a, greater than 1 and less than p." * run-length-encoding: 'lower case' -> 'lowercase' (exercism#1708) This makes it more consistent with another test: "description": "lowercase characters", Both forms are correct, but "lowercase" is more common. See: https://english.stackexchange.com/questions/59409 * isbn-verifier: 'isbn number' -> 'isbn' (exercism#1690) Most of the test descriptions just used 'isbn', so let's be consistent and avoid "International Standard Book Number number". * perfect-numbers: 'natural number' -> 'positive integer' (exercism#1691) There is no convention whether zero is a natural number, so let's avoid the issue. For example, see: - https://mathworld.wolfram.com/NaturalNumber.html - https://en.wikipedia.org/wiki/Natural_number - https://math.stackexchange.com/questions/283/is-0-a-natural-number The previous wording of ``` "description": "Zero is rejected (not a natural number)", ``` could be especially jarring for some tracks. For example, Nim defines `Natural` and `Positive` types, and `Natural` includes 0. See: - https://nim-lang.github.io/Nim/system.html#Natural Co-authored-by: Sascha Mann <[email protected]> Co-authored-by: Sascha Mann <[email protected]> * grains: Be more verbose in test-level descriptions (exercism#1707) The top-level `description` of these cases was: ``` "description": "returns the number of grains on the square", ``` but each test-level `description` contained only a number. The comments in `tests.toml` are generated only from the test-level `description`, and so the comments there will now be more informative than the previously seen: ``` # 1 "9fbde8de-36b2-49de-baf2-cd42d6f28405" = true # 2 "ee1f30c2-01d8-4298-b25d-c677331b5e6d" = true ``` * Add Style Guide (exercism#1713) * Add Style Guide * Update STYLE-GUIDE.md Co-authored-by: Sascha Mann <[email protected]> * Update STYLE-GUIDE.md Co-authored-by: Sascha Mann <[email protected]> * Update STYLE-GUIDE.md Co-authored-by: Ryan Potts <[email protected]> * Update STYLE-GUIDE.md Co-authored-by: Sascha Mann <[email protected]> * Update STYLE-GUIDE.md * Update STYLE-GUIDE.md Co-authored-by: Sascha Mann <[email protected]> Co-authored-by: Colin Caine <[email protected]> Co-authored-by: Ryan Potts <[email protected]> * CI: Add check that reimplemented-values are valid UUIDs (exercism#1702) Co-authored-by: ee7 <[email protected]> * CI: Use jq instead of grep/sed (exercism#1710) * Add esoteric example. (exercism#1717) * Square-Root: Add new exercise (exercism#1582) * Add square root exercie * Cite myself in metadata * Add radicand explantion, use PR as source_url * Add UUIDs, remove version * Adjust description.md Co-authored-by: wolf99 <[email protected]> * CI: Add workflow_dispatch as manual trigger (exercism#1711) This is useful for debugging CI or when working on a branch before opening a PR * security: CVE-2020-7598 (exercism#1706) * ⬆️ latest ajv-cli * 🔒 CVE-2020-7598 * Add abbreviations and restructure slightly (exercism#1718) * Add abbreviations and restructure slightly * Update STYLE-GUIDE.md * Update with better text * Update STYLE-GUIDE.md Co-authored-by: Colin Caine <[email protected]> * Update STYLE-GUIDE.md Co-authored-by: Colin Caine <[email protected]> Co-authored-by: Derk-Jan Karrenbeld <[email protected]> * Style: Fix whitespace issues (exercism#1720) * Style: Remove trailing whitespace With this commit, people who run `configlet generate` and commit the generated READMEs as-is will no longer introduce trailing whitespace into their track repos. * Style: Add missing final newlines * grade-school: Fix typo in test description (exercism#1689) * queen-attack: Fix typo in test description (exercism#1692) * Update nucleotide-count description (exercism#1719) See also exercism#1716. Thanks to SleeplessByte, rpottsoh, kotp, ErikSchierboom, etc :) * CI: Add /rebase command (exercism#1698) (stolen from v3 repo) * Add workflow recommendations and templates (exercism#1722) Adds a document that explains how to set up Continuous Integration (CI) workflows for an Exercism Language Track using GitHub Actions (GHA). It provides best practices and examples for you to use to make your own fast, reliable and robust CI workflows. Additionally, it provides GHA workflows. The GHA workflows can be adapted to work with any CI, track, or project, because the base structure will remain the same. * CI: Ensure immutability of test cases (exercism#1712) * CI: Check immutability of test data * Iterate old cases instead * Add to ci.yml workflow * Fix path to python script in workflow * Set chmod=+x for python script * Apparently latest does not mean latest * Fix path * Test mutated test in PR * Revert "Test mutated test in PR" This reverts commit 18dbfa2. * Fix build for workflow_dispatch triggers * Break out of loop early on failure * Fix typo * Handle removal of tests better * Add scenarios check * Update bin/check-immutability.py * Make variable names longer & use sys.exit instead of exit Co-authored-by: BethanyG <[email protected]> Co-authored-by: Corey McCandless <[email protected]> Co-authored-by: BethanyG <[email protected]> Co-authored-by: Corey McCandless <[email protected]> * Add test data for future edits to the script Co-authored-by: BethanyG <[email protected]> Co-authored-by: Corey McCandless <[email protected]> * rational-numbers: Make formulas more readable (exercism#1655) * rational-numbers: Make formulas more readable * Remove superscript characters * Readd parentheses * leap: fix typo (exercism#1726) * rational-numbers: Remove redundant factor (exercism#1727) If `b₁ = 0`, then `r₁` is not a rational number anyway. From https://github.com/exercism/problem-specifications/pull/1655/files#r421573667 * two-bucket: test inability to reach the goal (exercism#1580) 1. A test where the goal is too large. The student solution would need to either: * (If searching the state space) Notice that there are no further states to be visited, and yet the solution has not been reached. * Notice that the goal is larger than the larger bucket, therefore can be rejected immediately. 2. A test where the goal is not too large yet still can't be reached The student solution would need to either: * (If searching the state space) Notice that there are no further states to be visited, and yet the solution has not been reached. * Notice that the goal is not divisible by the GCD of the bucket sizes, therefore can be rejected immediately. In case the student assumes that all non-coprime bucket counts will invalidate the goal, a counterexample to that is given as well (buckets not coprime but goal is still possible). There are ten implementing tracks: bash csharp fsharp go java javascript python ruby rust typescript Of these tracks, only two of them (Bash, Go) currently test the condition where it is not possible to reach the goal. Having this test serves as a reminder that it remains wise to handle the situation where a search has not found its goal. It doesn't seem like this was discussed in the original submission: exercism/DEPRECATED.javascript#68 So it seems like it would be good to have a discussion of it on record. * [CI] Bump rebase action to fix CVE-2020-15228 (exercism#1731) * [CI] Only run immutability check on PRs (exercism#1730) Let's remove this until exercism#1728 has been resolved properly to avoid build errors on master. * Remove linkless words (exercism#1733) * build(deps): bump ini from 1.3.5 to 1.3.7 (exercism#1734) Bumps [ini](https://github.com/isaacs/ini) from 1.3.5 to 1.3.7. - [Release notes](https://github.com/isaacs/ini/releases) - [Commits](npm/ini@v1.3.5...v1.3.7) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Grade school exercise: A student cannot simultaneously be in two grades since the users' names are unique (exercism#1735) * Add configlet (exercism#1737) * change: add simplest test case (exercism#1739) * prime-factors: add further variations (exercism#1755) * [transpose] added 'jagged triangle' test (exercism#1748) * kindergarten-garden: completionist (exercism#1744) * list-ops: reimplement ambiguous tests (exercism#1746) * Format * Re-implement ambigious test cases * Clarifying comment * Re-add old versions of reimplemented tests * Remove accidantally commited executable * Clarifying commentary about integer division. * Add advice * Hamming: remove tests that don't make sense per 1761 (exercism#1762) * Hamming: remove tests that dont make sense * return tests & normalise error messages * grade-school: Change a UUID to be version 4 (exercism#1760) Commit 03529d0 (exercism#1735) added a new test case for the `grade-school` exercise, but the UUID added was version 1 rather than version 4. This was not caught by CI because the regex in the schema validator was too permissive (fixed by exercism#1759). Some reasons to prefer version 4 UUIDs: - Version 4 is the right version for a fully random and unique identifer; we don't want to indicate anything about the machine that generated the UUID, and version 1 UUIDs have a timestamp and MAC address component. - All of the other UUIDs currently in `problem-specifications` are valid version 4 UUIDs. - `configlet uuid` generates a version 4 UUID. - A reader familiar with the UUID specification (RFC 4122) might see a version 1 UUID and infer that the timestamp or MAC address component is useful, causing them to wonder why the others are version 4. - A user who generates a version 1 UUID might unintentionally leak their MAC address. See also: - https://tools.ietf.org/html/rfc4122.html * canonical-schema: Fix UUID regex pattern (exercism#1759) Commit cea02af (exercism#1676) added a UUID to each test case. However, the regex pattern that it added to the canonical schema was too permissive, meaning that CI would pass on a PR that added, for example, a version 1 UUID (see exercism#1735). Changes: - Use `a-f` instead of `a-z` - The third group must start with `4`. - The fourth group must start with `8`, `9`, `a` or `b`. * [CI] Verify that scenarios are defined in schema Co-authored-by: Josh Goebel <[email protected]> Co-authored-by: Victor Goff <[email protected]> Co-authored-by: Victor Goff <[email protected]> Co-authored-by: Katrina Owen <[email protected]> Co-authored-by: wolf99 <[email protected]> Co-authored-by: DagmarTimmreck <[email protected]> Co-authored-by: Michael Morehouse <[email protected]> Co-authored-by: Peter Tseng <[email protected]> Co-authored-by: Chris Couzens <[email protected]> Co-authored-by: Sam Warner <[email protected]> Co-authored-by: Gabriel Nelle <[email protected]> Co-authored-by: Chris White <[email protected]> Co-authored-by: traxam <[email protected]> Co-authored-by: ShaoWei Teo <[email protected]> Co-authored-by: Elena Parovyshnaia <[email protected]> Co-authored-by: Florian Keller <[email protected]> Co-authored-by: Ryan Potts <[email protected]> Co-authored-by: Ryan Potts <[email protected]> Co-authored-by: Peter Goodspeed-Niklaus <[email protected]> Co-authored-by: Pranas Ziaukas <[email protected]> Co-authored-by: Jeremy Walker <[email protected]> Co-authored-by: Rafael F <[email protected]> Co-authored-by: Zuzanna Kru <[email protected]> Co-authored-by: Bruce Park <[email protected]> Co-authored-by: Tejas Bubane <[email protected]> Co-authored-by: Jubilee <[email protected]> Co-authored-by: Charles Ross <[email protected]> Co-authored-by: Ole Kröger <[email protected]> Co-authored-by: DmitrySamoylov <[email protected]> Co-authored-by: Colin Caine <[email protected]> Co-authored-by: Sascha Mann <[email protected]> Co-authored-by: Corey McCandless <[email protected]> Co-authored-by: wolf99 <[email protected]> Co-authored-by: wolf99 <[email protected]> Co-authored-by: Kirill Artamonov <[email protected]> Co-authored-by: ee7 <[email protected]> Co-authored-by: Derk-Jan Karrenbeld <[email protected]> Co-authored-by: Derk-Jan Karrenbeld <[email protected]> Co-authored-by: BethanyG <[email protected]> Co-authored-by: Yunseon Choi <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Pedro Rolo <[email protected]> Co-authored-by: peerreynders <[email protected]>
Over the last few months there have been a number of passionate debates in this repository about new exercises and changes to the existing exercises. Maintainers often have very opposed views and cannot reach a consensus. This has lead to lots of frustration from people who all want to make Exercism better, but disagree on how that should be done.
This is a clear sign that the product team have not done enough to communicate guidelines around how exercises should be structured and how this repository should be structured. The reason for this is that the product team don't know how exercises should be structured or how the data in this repository should be structured.
This repository (and exercises on Exercism in general) have evolved organically without much structure or thought. For V1, this was generally ok, but since V2, where exercises are part of learning pathways and where everything is a bit more complicated in general, this has now become a real problem. We in the product team therefore need to go away and do some proper work around understanding how exercises should evolve in Exercism. Once we've got some clarity on that, we can then start to put together some clarity around how this repository should work, and everyone can move forward, hopefully without the uncomfortable conversations that have been ongoing recently.
Therefore, for the time being, we are closing this repository to any new exercises, or any changes-of-substance to the canonical data. We will still accept bugfixes (if tests are wrong) and improvements to the copy around exercises, as long as they do not alter the substance of an exercise. If you would like to add a new exercise to your track, please do it as a track-specific exercise for now, and we can discuss generalising it into this repository further down the line.
I want to finish with a personal apology that I haven't realised this a bit earlier and stepped in before people ended up clashing over things. I'm excited about getting this to a really good place and making both the Tracks the best they can be, and ensuring that maintainers lives are as easy as possible.
The text was updated successfully, but these errors were encountered: