category reshuffle

[schorsch]

Until now we used the category in the question object and the folder name.

We want to compress the folder structure on the top level with only four main folders(categories). This would lead to a mix of lots of different coding lang-question being in the same folder.

How to ensure proper categories and keep the structure logically?

Proposal:

• we keep the categories like now and nest them within new folders
• we add the new top folders as category and use the existing ones as a new subcategory

[koos]

I prefer more general top categories. But what could they look like?

[schorsch]

I will add our existing categories folders as enum to the json schema, as we need to ensure to not get a category jungle

[dhoelzgen]

I think it's done. Can we close this issue?

[a2800276]

ugh! ugh! ugh! it's already very unuebersichtlich with only 150 questions, weren't we hoping for substantially more? I don't think the "everything in one directory" scheme will scale very well...

[dhoelzgen]

Hmm, but putting them into directories for categories would make no sense I think, they are too generic. Do you think putting them in folders for sub categories would be a good idea? Don't know how many we'll eventually have, and if it really helps you to find out if a question already exists.

[schorsch]

i would go for sub-folders too and can move everything around. Such a structure is also more accessible to users as they can directly scan the availble sub-cats

[a2800276]

While I'm complaining: the category/subcategory thing doesn't make sense to me (e.g. categories "frontend" and "backend", no category "programming", category "culture" and subcategory "culture" ...) especially the explicit limitation of categories in the schema: are questions about "hardware", "c", "sql", "java", "erlang", ... not allowed?

Also, no creator_email?

AND I don't like wrapping {{question: { the actual question}} ...

Admittedly the last two points just bother me and I don't really care, but the cat/subcat thing and restricting the categories is wrong IMO...

[schorsch]

We can easiely allow more cats and choose the enum approach to prevent uncontrolled growth of the list.
No problem to add "c", "sql", "java", erlang, .. if we have got questions for it.
In terms of hardware i would rather suggest more specific types.

Yes no creator_email

the creator field was supposed to be free of any type and we added twitter+github to be able to connect to social networks. I dont really favour more creator fields because of the clutter and the resulting need for a separate creator object, which would it make harder to build/read questions. I can change the description for the creator field => ".. name or email .."
Personally i dont like to have my email in public and they change, but that might be different with others.

Nesting:

We like to be explizit, an this leaves room for future enhancements e.g own creator or answer objects on the top level