Wiki maintenance

Development Learn to Contribute
#1

Starting a new topic on maintenance and planning around the SC Wiki. :pencil2:

#2

The wiki has lots of outdated info, crusty pages, and could be more useful.

Having started a bit on the task, I see it’s a bit ambitious to aim for a complete overhaul. I don’t want the perfect to the enemy of the useful, so I’d like to make incremental changes that start with reorganizing, building in a bit of structure, and consolidating some of the more high-traffic pages.

As a first step, I’ve mocked up a new, slimmer home page and sidebar on my SC fork.
(Note many links are just placeholders.)

The goal with it is to make all wikis visible from the sidebar, but using a nested structure to have the most useful visible (no more than 3 per level-1 heading), with the rest in categorical dropdowns.

This way, we can hopefully 1) discover what’s there more easily, and 2) see we have a lot of redundancy or dust to clean up.

How to move forward?

I’d like to hear feedback on this proposed structure (knowing it can/will evolve), and hear of other ideas people would like to see in a revised wiki.

Is this something that should be an RFC?
Or can we organically discuss here and make incremental changes?

For example, here are a few ideas on improvements, to give an idea of the kind of discussion it may/not evoke:

  1. (already mocked up) Create a new sidebar with a nested structure 2 levels deep. Pluses: All pages can be found, 2 levels of categories for navigation. Downside: nested structure require html (though the template is now made and will change infrequently)

  2. Add tables of contents to all wikis that have more than 3 header tags or extend beyond ~3 page heights.

  3. Move all “WIP” wikis out of that state — we accept that wikis are by nature works in progress, and WIP wikis tend to stall because of the label.

  4. Add a wiki about the wiki, which includes style suggestions.

There’s likely another 5 or 10 similar suggestions… Should I float them all before implementing them, or, given it’s a wiki, should I roll them out them point back to them to draw attention for feedback?

1 Like
#3

Thanks for taking the initiative here! totally agree the wiki needs love…

my inital reaction is yes so much better to see “Contributing to SC” the first item in the sidebar instead of a guide to fedora!!!

I’d say roll out your ideas and let the rest of us complain afterwards. I’m excited to jump in and do clean-up and proofing where I can

#4

…but sadly the wiki can only be edited by folks with project write privileges :frowning:

Right there on the first page is an invitation to

Join the sc-users and sc-dev mailing lists.

which have been closed for 3 years. …grrrr

#5

Thanks for your thoughts @semiquaver! It was your questions at the last sclang meeting that brought me back around to the wiki, remembering at some point I’d started to write up a wiki on some of the dev processes people often ask about :slight_smile:

I’ll let this discussion go for a week or so before making any big changes.

I don’t have permission to edit the access control list, @josh ? @MarcinP ? Could we give @semiquaver permission for editing the wiki?
@semiquaver — I did a quick search and couldn’t find ‘semiquaver’ on github, do you have a different handle there?

#6

Thanks Mike I’m cdbzb on GitHub…