You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Track Anatomy Project has arrived for Python! This issue covers what that means for this track and what maintainers can expect to see throughout the process.
Background
Rationale
Our research has shown that having a suboptimal track structure causes frustration for students and a significantly worse experience for mentors. The primary cause of this is that historically Exercism exercises were not implemented with any particular purpose in mind. Both exercise choice and sequencing were mostly incidental. In the past couple of years, we've come to understand that the principal purpose of Exercism is to optimize for achieving fluency. Reworking the tracks with this focus improves the experience for both students and mentors.
The project
We have spun up a project to tackle these problems. We've named the project the Track Anatomy Project, and you can read more about the background in the introductory blog post.
The goals of the Track Anatomy Project are:
to design the optimal path for progression throughout the track. We want to make sure that the key topics are covered explicitly, in a suitable order.
to ensure that progression is consistent across language tracks (where appropriate).
to optimize the track for fluency in the data structures, language features, standard library, and conventions/idioms of the language. Fluency means that the goal is for the student to be able to express themselves comfortably in the basics of the language and that their code should not be jarring to experienced users of the language. It does not aim to teach people to get better at programming (though that is sometimes a side-effect).
The tool
To reach these goals, we've developed a tool to help maintainers work through the restructuring step by step. The working title of the tool is The Track Anatomy Tool.
The task of restructuring a track is significant. To make this restructuring achievable, we've split the process into several phases, where each stage addresses one specific aspect of the restructuring. Together, the phases work from coarse-grained to fine-grained, and from the beginning of the track to the most advanced exercises. The end result will be a restructured track, with a list of improvements that need to be made, as well as a set of guidelines for the track to make it easier to make decisions about suggested improvements in the future. The methodology is the same for all tracks. The outcome is different for each language.
We have tested the tool on the Ruby and C# tracks, and in both cases, it resulted in dramatic improvement for both students and mentors.
What this means for Python
We have invited the first pool of maintainers to work with the Track Anatomy Tool and apply it to their language. This track is one of those chosen, and @yawpitch has volunteered to do the work.
@yawpitch will be working quite closely with @F3PiX, who is leading the work on the Track Anatomy project.
Many small PRs
The restructuring process results in a lot of small PRs.
We encourage this project to be run like a series of refactorings: small and regular changes, where we address the simplest problems first, without striving for perfection. After each change is merged, we monitor the results and tweak based on our findings. Then we make the next small change.
We focus on the core progression first, either leaving the side exercises alone or taking pragmatic actions to redivide them. The side exercises will be addressed in more depth later on.
The process gradually builds up a big picture that will not be discernible in any single pull request. This big picture is never clear at the start of the restructuring; it gradually develops as the maintainers work through each phase of the process.
This means that unlike most earlier work on Exercism language tracks, individual pull requests will be more difficult to discuss as one-offs, as they tie into a large, complex, and often unclear picture. We understand that this can be a bit disconcerting for maintainers who are not deeply involved in every step of the Track Anatomy Project for this track but ask for your trust in the process.
Mildly confusing for students
The changes will lead to some confusion for active students, due to changes in the order or the state (core/side) of exercises. We have decided that the advantages of the small changes outweigh the confusion they may cause.
How can you help and contribute?
Most changes in the upcoming weeks are first and foremost pragmatic choices, based on what the tool is asking. None of the changes are final, and none of them pretend to be the perfect solution to all that matters in the track.
To help this process along, we ask that you give the person working through the tool room to experiment. In PRs, help find technical and mechanical problems and clerical errors rather than questioning the underlying reason for the change.
Keep an eye on issues with the label Track Anatomy. You can contribute by implementing new exercises, or researching how such an exercise can be solved in your language. Since the main focus of the tool is on the core exercises, it would also be valuable to help address issues in the side exercises that happen as a side effect of restructuring.
Most importantly, you can help by mentoring, improving mentor notes, and providing feedback on your mentoring experience as a result of the implemented changes. Let us know if mentoring got easier or harder, more fun or less, and share your observations about the result of a change, either in issues here or in the Slack track channel.
Final thoughts
We are fully aware that the tool is a black box, and the inner workings can seem mysterious. We're not being secretive, it's just a matter of (a) mental bandwidth and resources and (b) things are changing so rapidly that documenting them is very hard.
Our primary focus is to facilitate the folks who are working through the process on the track, and we ask for your patience in the process.
We're confident this will lead to the best outcome for the Python track! If you have any questions, please ask them here :)
The text was updated successfully, but these errors were encountered:
@cmccandless -- should we be leaving this open to remind us to look at and restructure the practice [V2] exercises as we move to V3 .... or should we close this in favor of an issue that focuses on mapping V3 concepts to practice exercises?
The Python Track Anatomy
The Track Anatomy Project has arrived for Python! This issue covers what that means for this track and what maintainers can expect to see throughout the process.
Background
Rationale
Our research has shown that having a suboptimal track structure causes frustration for students and a significantly worse experience for mentors. The primary cause of this is that historically Exercism exercises were not implemented with any particular purpose in mind. Both exercise choice and sequencing were mostly incidental. In the past couple of years, we've come to understand that the principal purpose of Exercism is to optimize for achieving fluency. Reworking the tracks with this focus improves the experience for both students and mentors.
The project
We have spun up a project to tackle these problems. We've named the project the Track Anatomy Project, and you can read more about the background in the introductory blog post.
The goals of the Track Anatomy Project are:
The tool
To reach these goals, we've developed a tool to help maintainers work through the restructuring step by step. The working title of the tool is The Track Anatomy Tool.
The task of restructuring a track is significant. To make this restructuring achievable, we've split the process into several phases, where each stage addresses one specific aspect of the restructuring. Together, the phases work from coarse-grained to fine-grained, and from the beginning of the track to the most advanced exercises. The end result will be a restructured track, with a list of improvements that need to be made, as well as a set of guidelines for the track to make it easier to make decisions about suggested improvements in the future. The methodology is the same for all tracks. The outcome is different for each language.
We have tested the tool on the Ruby and C# tracks, and in both cases, it resulted in dramatic improvement for both students and mentors.
What this means for Python
We have invited the first pool of maintainers to work with the Track Anatomy Tool and apply it to their language. This track is one of those chosen, and @yawpitch has volunteered to do the work.
@yawpitch will be working quite closely with @F3PiX, who is leading the work on the Track Anatomy project.
Many small PRs
The restructuring process results in a lot of small PRs.
We encourage this project to be run like a series of refactorings: small and regular changes, where we address the simplest problems first, without striving for perfection. After each change is merged, we monitor the results and tweak based on our findings. Then we make the next small change.
We focus on the core progression first, either leaving the side exercises alone or taking pragmatic actions to redivide them. The side exercises will be addressed in more depth later on.
The process gradually builds up a big picture that will not be discernible in any single pull request. This big picture is never clear at the start of the restructuring; it gradually develops as the maintainers work through each phase of the process.
This means that unlike most earlier work on Exercism language tracks, individual pull requests will be more difficult to discuss as one-offs, as they tie into a large, complex, and often unclear picture. We understand that this can be a bit disconcerting for maintainers who are not deeply involved in every step of the Track Anatomy Project for this track but ask for your trust in the process.
Mildly confusing for students
The changes will lead to some confusion for active students, due to changes in the order or the state (core/side) of exercises. We have decided that the advantages of the small changes outweigh the confusion they may cause.
How can you help and contribute?
Most changes in the upcoming weeks are first and foremost pragmatic choices, based on what the tool is asking. None of the changes are final, and none of them pretend to be the perfect solution to all that matters in the track.
To help this process along, we ask that you give the person working through the tool room to experiment. In PRs, help find technical and mechanical problems and clerical errors rather than questioning the underlying reason for the change.
Keep an eye on issues with the label Track Anatomy. You can contribute by implementing new exercises, or researching how such an exercise can be solved in your language. Since the main focus of the tool is on the core exercises, it would also be valuable to help address issues in the side exercises that happen as a side effect of restructuring.
Most importantly, you can help by mentoring, improving mentor notes, and providing feedback on your mentoring experience as a result of the implemented changes. Let us know if mentoring got easier or harder, more fun or less, and share your observations about the result of a change, either in issues here or in the Slack track channel.
Final thoughts
We are fully aware that the tool is a black box, and the inner workings can seem mysterious. We're not being secretive, it's just a matter of (a) mental bandwidth and resources and (b) things are changing so rapidly that documenting them is very hard.
Our primary focus is to facilitate the folks who are working through the process on the track, and we ask for your patience in the process.
We're confident this will lead to the best outcome for the Python track! If you have any questions, please ask them here :)
The text was updated successfully, but these errors were encountered: