Q: data organization (long term)

[Blind4Basics]

in content/snippets, all snippets aren't really discoverable. That's not a problem for now, but once their number grows, it might become very hard to find "the snippet you wanna update or check against a new idea that already exists".

Also, the organization is totally opaque for now. It seems that poly_0001 is storing initial solutions in various languages?

Suggestion:

Use human friendly slugs? possibly adding an automatic ID at the end to enforce uniqueness?

Example:

    snippets/init_sol_0001/python_0001
                          /python_0002
                          /kotlin_0003 (or 001?)
            /random_tests_0002/...

[hobovsky]

I agree that discoverability and organization of snippets is not very clear, but I have no good idea how to handle it. For the time being, I hope that all management of content will be done by maintainers of the script, and users won't have to bother, they just request or propose snippets via issues board. Ideally, content could be managed with a tool, and things would be easier when the library would be stored in a database, and not in file system.

The poly_XXXX folders are not technically required, they are a convention of collecting all translations of one kind of snippets in a single folder. This would hopefully make it easier to update snippets in all related languages when an idea or a pattern changes. But still, finding a corresponding poly_XXXX folder is not easy.

[Blind4Basics]

if ever the number of scripts becomes large, you'll at least need a way to allow an user raising an issue about one snippet to point exactly the location of your script in your file system. Otherwise you'll get crazy, at some point, "searching-for-the-damn-snippet".

Maybe a right click on the snippet that is showing the path of the snippet? or a tooltip showing it? or both?

A possibility to copy it to the clipboard would be even better. Context menu:

• option to copy snippet
• separator
• showes the path
• option to copy path to clipboard

[hobovsky]

Yes, possibility of easily identifying snippets would be good, and, at some point, necessary. For example, the #6 requires the snippets to be identifiable so they can be pointed to. I would also like to make them shareable, so reviewers could paste links to them to support authors ( "hey, you need to use an assertion with tolerance here, see this link how to use it" ). But identification of a snippet is not necessarily related to "browsability" of the library. Both things are good to have, but they don't necessarily have to be solved the same way.

I plan to display some more details of a snippet than just its markdown content. I just did not decide yet what, where, and how.