Add a landing page with the list of available demos to run

[purplesky2016]

Motivations:

1. The number of yml files in this package is growing, and not all of the yml files are interviews: some of them are "package" files for easy reference from outside. Adding a list will filter out the non-interview files.
2. We can add a brief descriptions to each interview on the list, so that users can get a quick idea of which tool is used for what purpose without having to click each individual yml file.
3. Having such a landing page can provide an operational link to be posted on the document site for users to check them out without hassle.

Question: do we need to have a name convention for the yml files? If so, should we fix the existing ones?

[nonprofittechy]

Agreed, good idea. Also we do have documentation for some of these here already: https://suffolklitlab.org/docassemble-AssemblyLine-documentation/docs/framework/altoolbox so maybe we link to that. But agreed it should be clear somewhere from just the repo where to go to learn more.

@plocket suggested having a "package" YAML file for each interview to include (without any special extra name, just e.g., 3partsdate.yml), and then a _demo.yml to demonstrate the feature. That's a good convention for us to follow I think.

[purplesky2016]

Great, that page is a perfect place for the new link, and the landing page will complement it with a hands-on experience.

Okay, for package file names we use one word like 3partsdate.yml. Question - If a module and a css are involved, it makes sense to have a "package" file; but if only a module is involved, having a package file doesn't seem to provide any "savings"?

For demo file names, do we use underscore_lower_case_demo.yml?

[nonprofittechy]

1. Agree that if there is only a module, having a package file name probably isn't needed. We could still include a _demo file. It might be worth adding the package file anyway, just to be consistent?
2. Yes, the demo file convention is underscores lower case (snake_case)

[purplesky2016]

1. Agree that if there is only a module, having a package file name probably isn't needed. We could still include a _demo file. It might be worth adding the package file anyway, just to be consistent?

Yes, naming a demo as xxx_demo is always a good choice. Adding a package file when it's not called for would increase the number of files quickly. Alternatively, we could just add another convention:

3. If the module is not part of misc.py, then name the module using one word just like the package file. That would make it consistent from the user perspective.

I can add these rules to the landing page for ongoing additions.

As for the existing ones, do we need to fix them (rename/delete), or just "list" them using the convention? I.e. use some functions to manipulate the display of the name?

[nonprofittechy]

1. Before we rename any, we should do a quick GitHub search to see if anyone is using them with the old name.
2. I think some of these were just experiments that weren't used anywhere, so can be safely renamed.
3. If they are already being used, we should fix in the upstream package if we own it.
4. If that's not possible, we may want to just keep the old name for backwards compatibility. (We could also make a new file that points to the old file to make it backwards compatible, if the name we want people to use isn't possible)