Open pull requests on all tracks to normalize topics

[kytrinyx]

Figure out what the conclusion is in https://github.com/exercism/discussions/issues/167 and submit pull requests to each track to normalize per those conclusions.

[tleen]

One thing I am still not clear on: can tracks use topics not in the master list? As this moves forward will all topics have to be centrally controlled? The more I dig into config files the more I find that topics not on the TOPICS.txt file are included. Should we pull those into TOPICS.txt?

[kytrinyx]

can tracks use topics not in the master list?

Yes, absolutely! What we're aiming for in the TOPICS list is the topics that are generally useful for more than one track. This will help us be consistent when we actually mean the same thing (but not force us to be consistent where it doesn't make sense).

As this moves forward will all topics have to be centrally controlled?

No, I don't think that is useful.

Should we pull those into TOPICS.txt?

I think it would be worth having something that automatically lists out topics that are not on the list so we can evaluate whether or not they're in the bucket of "probably useful for lots of tracks" topics.

[tleen]

@kytrinyx attached is a (zipped) dump of all topics, frequency and track use. It is in CSV format so you can view as a spreadsheet. I had to lowercase all the topics to keep things from artificially splitting.

exercism-topics.csv.zip

[kytrinyx]

@tleen This is awesome, thank you!

[tleen]

If it is helpful to anybody I formalized the tooling used to get that data dump above. Some quick command line tools to help get an overall understanding of all the configurations in Exercism. It is still sort of rough but works. This is more of meta configuration analysis so I did it separately from configlet which generally handles configuration on one track at a time. It is mostly to get my head around how other tracks are handling the re-configuration.

There are three sofar, if anyone else can find them helpful:

• exercism-config-to-csv - turn a single track config file into a CSV for viewing as a spreadsheet
• exercism-uniconfig - collect all the track configurations into to one big JSON file (a uniconfig)
• exercism-config-visualizations - a bunch of different reports to mine the uniconfig data. Found some interesting stuff. Like hello-world is not the most implemented exercise (29 times), it's actually hamming (30 times)!

You can now recreate the topics data above whenever needed:

exercism-uniconfig | exercism-config-visualizations topics --format csv

Also interesting: average difficulty and number of topics per exercise across all tracks (see how alike ecmascript and javascript are):

Track	Diff	Topics
bash	1.50	1.93
c	2.63	3.11
clojure	1	0
coffeescript	1	0
cpp	4	2.03
csharp	4.59	2.17
dlang	2.56	2.50
ecmascript	4.48	4.97
elixir	3.60	0.64
erlang	3.68	0
fsharp	4.76	2.09
go	3.77	3.32
groovy	2.62	1.31
haskell	4.49	0.79
java	5.38	0.08
javascript	4.51	4.95
lisp	1	3.93
lua	4.05	3.09
objective-c	3.12	2.24
ocaml	4.85	1.27
perl5	1	0
perl6	1	0
php	2.19	1.62
plsql	1	0
powershell	1	0
python	1.34	0.70
r	2.10	2.03
ruby	1.10	0.16
rust	4.29	2.87
scala	4.51	3.01
sml	1	0
swift	3.79	2.06
vbnet	1	0

[kytrinyx]

This is so great, @tleen!

[ilya-khadykin]

@tleen, thanks!

[Smarticles101]

@tleen these are really interesting stats!

[tleen]

Yeah fun isn't it? :smile:

[tleen]

I can't tell if this is a thing for nexercism. Seem like bash and r have gone full fledged into lowercase_underscore_slug mode, the rest of us not_so_much. It seems to work just fine if we don't. At the same time, change can catalyst change. I'm spending time on tightening up TOPICS, do we want to normalize this for Nextercism?

[iHiD]

Lower case underscore would be perfect. We can titleize them in Rails then where appropriate. Also, short is better where possible, so that we can display as many as possible next to an exercise on a card. Thank you.

[robphoenix]

Lower case underscore would be perfect.

Be good to also consider what to do with topics such as Control-flow (conditionals) - control_flow_(conditionals) or control_flow_conditionals?

[ilya-khadykin]

Be good to also consider what to do with topics such as Control-flow (conditionals) - control_flow_(conditionals) or control_flow_conditionals?

Voting for control_flow_conditionals

[robphoenix]

Once we get a confirmed consensus it's a fairly simple update to the configlet fmt command, which can then be used on each track.

[kytrinyx]

It sounds like there's consensus here on all lowercase with underscores, no parens (or other special characters).

That sounds very sensible to me. I'm going to go ahead and make the call.

[iHiD]

For "control_flow_conditionals" can we just have "conditionals" please? Simpler for beginners (one jargon word not three) and shorter so we can fit more of them on cards.

On Tue, 22 Aug 2017, 15:20 Katrina Owen notifications@github.com wrote:

It sounds like there's consensus here on all lowercase with underscores, no parens (or other special characters).

That sounds very sensible to me. I'm going to go ahead and make the call.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/exercism/meta/issues/83#issuecomment-324041426, or mute the thread https://github.com/notifications/unsubscribe-auth/AARfDIqMnLX_nuWy07B-jd4Ls1fYNEa6ks5sauOogaJpZM4OuwlE .

[tleen]

controlflow* are an odd group of topics, they are massively general and as such probably inconsistently used everywhere. I tried to avoid them unless there was something about the control flow that made it a core requirement of the exercise. Control flow is an aspect of almost any non-trivial program. Its like having a topic for variable_assignment. I would be in favor of either merging them all into a control_flow topic or removing them altogether.

[kytrinyx]

controlflow* [...] are massively general and as such probably inconsistently used everywhere.

I struggled with this one when trying to restructure the bash track. It felt like the first time if statements or for loops or while loops are introduced, it's useful for it to be a real topic, but the rest of the time, not so much.

[tleen]

Would it make sense to rewrite the TOPICS.txt list in lower snake case now? This would suggest that topics be added in that format.

[kytrinyx]

@tleen that would make a lot of sense.

[robphoenix]

For "control_flow_conditionals" can we just have "conditionals" please?

We can either change this in the topics list and ask for it to be changed in track config files, or we can update configlet to remove the control_flow_ suffix.

I think the topics list should reflect what is actually on the site, and while it's possible to remove control_flow_ within configlet, this opens up the possibility for having to account for any number of corner cases. It would be good to get this sorted sooner rather than later as configlet has been released with the fmt command and so currently it is formatting incorrectly.

[kytrinyx]

We can either change this in the topics list and ask for it to be changed in track config files, or we can update configlet to remove the controlflow suffix.

I think it's worth sorting this out at the TOPICS level. Configlet could do it, but it would seem more like a dark art if it's not listed the way we want it up front.

[kytrinyx]

This has been done as part of #95