Problem-specifications: DOT DSL: Exercise goal is not clear in the description

[aburd]

Tonight I started to do the “DOT DSL” exercise in the Rust track. The goal of the exercise is stated as:

Write a Domain Specific Language similar to the Graphviz dot language.

This sounded rather difficult to be honest, but interesting, so I read on. I read the example provided about the Dot language and the documentation provided on the Builder pattern. Only after downloading and reading through the tests was I able to grasp what the exercise was trying to get me to do, which is creating structs using the builder pattern. My first impression was that the exercise may have been about trying to parse some text into an AST or something of that sort, but was actually a bit easier and more practical.

After pressing the back button from the description page, I noticed the tags: "builder pattern, derive, modules". After that, everything started to click.

I fear this description may scare some students off, and it's a shame because I really liked the exercise itself after getting to know what it was about.

I hope I'm not being too forward, but here are some concrete steps that could be taken to guide the students a bit more.

1. Change the first phrase from

Write a Domain Specific Language similar to the Graphviz dot language.

to something like

Build a data structure that is similar to the Graphviz dot language

1. Add some small sections beneath the links to the materials about the builder pattern, to the Graphviz dot language and documentation on Rust modules

Of course, if this is not in the spirit of exercism, feel free to let me know!
But with some feedback, I'd be more than happy to submit a PR as well.

Thanks for your time.

[coriolinus]

You're not being too forward; it's always useful to have feedback from students progressing through the track, so we can improve things.

However, this isn't the right place to implement the change. The README containing that text is autogenerated from the description in the problem-specifications repo; one of the CI checks for this track ensures that they don't get out of sync.

Community improvement is very much in the spirit of Exercism. I am going to transfer this issue to the problem-specifications repo, where there is a larger group of people active, and where this can lead more directly to a PR fixing the issue.

[kotp]

However, this isn't the right place to implement the change.

This is now the right place to implement the change.

[kotp]

@aburd Definitely a good idea. Are you interested in creating the required pull request (also known as a PR), which will let it be reviewed, and hopefully accepted?

[aburd]

@coriolinus
Many thanks for transferring this issue to the correct place! I've starred this area in case I find something else that may need improvement.

@kotp
I would love to submit a pull request for this! I can't do it tonight (in Japan), but I can have something up by tomorrow night so the review process can be started. For now, I'll read the PR guidelines and look at some successfully merged PRs, so I can get a feel for the process.

If there is any other materials that should be reviewed beforehand, please let me know.

@SleeplessByte
Thank you for adding labels!

[rpottsoh]

@aburd, when you create your PR please link it to this issue. In your first comment state at the beginning of a line:

fixes #1537

or

resolves #1537

Then give some highlights of what is being covered. If anyone wants more details they will be able to click #1537 and be sent to this issue.

When your PR is eventually (probably) merged, the act of merging will automatically cause this issue to be closed.

Good luck with the PR and thanks for helping out!

[aburd]

@rpottsoh

Many thanks for your guidance! I'll be sure to do that.