The instructions in the Python Meetup exercise do not mention that there is a descriptor called “fifth” that you need to code for, that is, the fifth weekday of the month, and that it is this descriptor that can raise exceptions. I’d like to create an issue and send a PR to fix this, but I am supposed to post here first, correct?
Hi @ksnortum 
Thanks for posting. The Meetup exercise for Python (and almost all other practice exercises on the track) share a cross-track repository for problem descriptions and test data called problem-specifications . The description for Meetup is here.
You should discuss this change in the general Exercism channel here on the forum, and PR to problem-specificiations. Once the PR is approved and merged, all tracks can then sync the changes.
I can’t change the category of this post, but if you open a new one in Exercism , you can link back here.
Admin note: I’ve moved it 
In the description of the Meetup exercise, it says:
The descriptors you are expected to process are:
first,second,third,fourth,last,teenth.
I would like to change that to first , second , third , fourth , fifth, last , teenth . This adds fifth, a descriptor that is tested for but not mentioned in the description.
Should I create an issues, a PR, or either?
Cons: Adding a “fifth” would break any existing solutions if tracks were to sync that change.
What are the benefits of extending this exercise with a “fifth”?
The program meetup_test.py has tests that use fifth already, in fact, you can’t pass the test without your solution handling fifth (line 303 and following). I’m proposing changing the description to match the test.
I take a look at the python exercise and indeed they have implemented tests for fifth, and noted as # Additional tests for this track. Not sure when it happened but I solved it two years ago and it already there.
But when I implement this exercise for PS from the specs, those tests are not there. So I suppose the text change should only be for python track?
In that case you’re looking at adding an instructions.append file that goes after the instructions synced from problem-specifications. If you edit the text of the instructions.md, you risk losing that the next time somebody syncs content from the problem-specifications. Adding track -specific bits to the append file means they won’t be overwritten by a future sync.
However, the test suite is the definitive source of truth, not necessarily the instructions, so it’s important to read the tests as well to see what the expected inputs and outputs are.
It looks like there already is an instructions.append in the Python track. I guess that’s where the changes would be put. It just seems odd to say what all the week descriptors are and then add one at the bottom, but okay. Maybe there isn’t any other good way to do it.
My apologies, @ksnortum!
Was in a hurry earlier and completely forgot that we’d done additional tests for this exercise in Python, and deviated from problem-specs.
Yes – the instructions.append.md is the place you should make this change. Yes - it is a bit awkward, but as @BNAndras has pointed out, that is the way you customize things to prevent them being overwritten on sync to problem-specs.
Here is an example from the linked-list exercise where we’ve pointed students to different requirements/instructions. The convention is to use the heading
How this Exercise is Structured in Python to flag it for students.
Please go ahead and open a PR (it will close, but I can re-open and review it for you) on the Python track. Please also take a look at the additional_tests.json file to make sure your instructions.append is in line with the tests listed there.
Thanks for your patience and efforts! 
Okay, there is this PR now for this issue:
I’ve reviewed and left comments. 
Looks good!
Merged. Thanks for the PR!