Determine feature requirements for alpha milestone

[pcardune]

I'm aware of features that we have partial or limited support for, or which are currently buggy or simply not finished yet (comments, search, animations, a11y). We need to decide which features are must-haves for which milestones so we can prioritize work to finish them, fix them, or disable them (until they are ready). I'm inclined to remove, disable, or hide any features that aren't strictly necessary for the alpha milestone so we can prioritize work on alpha.

Assigning this to you @schanzer since you know what the teachers will need to try out wescheme-blocks in January.

[schanzer]

I've added all the issues that deal with:

• Overall code quality
• Regressions or heisenbugs
• Test coverage for existing code
• Rapid deployment, bug reporting, or bug replaying

My thinking is is that new features and/or not-essential improvements don't make the cut, but anything that stabilizes the existing codebase does. If you're happy with this logic, feel free to close. Otherwise let's discuss here or by phone?

[pcardune]

What about comments? Is that a new feature or a non-essential improvement? Or is that just an unstable part of the existing codebase that should be stabilized for alpha? I guess I'm just confused about which features fall into which categories?

[schanzer]

Ah, you're absolutely right - comments belong in alpha, since we're targeting the PLT folks there. Now every issue in our tracker has a milestone. Is there any other item that's not represented in an issue?

[pcardune]

Anything targeting the PLT folks should be pre-alpha. alpha is for teachers.

I think everything else has an issue, but I'm sure we'll come across more things as we test stuff out. Do you want to make an issue for the hour of code lesson?

[schanzer]

Done. OK to close this issue?