How can we make the site (mostly) self-sustaining?

Site Feedback and Other Questions
#1

Right now, we're all working very hard to get the site to where we want it to be. This is good.

Six months from now, I would like to us to be in a position that no one person is critical to maintenance/evolution/improvement of the site. Take a moment to think about how to set up the site so that any of us could take a year to go to the South Sea Islands...

  • We certainly don't want to write/be writing all the text on the site ourselves.
  • What things must we write ourselves? (We certainly have to handle the site organization, top-level pages, Flashing instructions, importing ToH data, set up ToH display... What else?)
  • How much can we rely on people (outside this core team) to continue to add value/knowledge to the site? (Adding a device through the ToH machinery makes its presence known automatically. That's good.)
  • How can we encourage new members to add data about devices, about packages, etc. so the site improves organically?
  • Is the core team doing a lot of work (or setting up a system to handle a lot of data) to produce pages that aren't absolutely needed, or don't improve the signal-to-noise ratio? For example:
    • As @bobafetthotmail pointed out, the quality of Packages is wildly variable. Some are useful, some are documented, some are neither. I worry that automating the display of all the packages just hides good ones amongst the rest. I would say it's better to encourage people (the package authors, or other motivated individuals) to create HOWTO pages (a la OpenWrt) that do a good job of describing the package. We can then link to those articles from a top-level HOWTO pages.
    • I will confess that I don't fully understand the Architecture descriptions, but I don't see the use case for those pages. (Maybe I just need to read more carefully...)

Thanks for listening.

#2

[quote="richb-hanover, post:1, topic:187"]Six months from now, I would like to us to be in a position that no one person is critical to maintenance/evolution/improvement of the site.[/quote]You wish... when we signed up it was for life, lol.

Once the real work is done, maintaining is relatively easy and takes little time. Development pace isn't so fast to require you to rewrite articles, you might have to change a line here or there every now and then.

How much can we rely on people (outside this core team) to continue to add value/knowledge to the site?

I wouldn't rely on random people that much. Random people come and go at random. I mean random users are not bad, just they are not reliable.

How can we encourage new members to add data about devices, about packages, etc. so the site improves organically?

Already said, by showing that there isn't a whole ton of things to shovel around, but by showing that there are only minor fixes to do. And for that to happen, someone must have done most of the shoveling already.

I think new members and random edits can deal with regular mainteneance, but won't really be able to deal with getting the wiki in shape.

I worry that automating the display of all the packages just hides good ones amongst the rest.

I think I already stated that the idea is making different tables, not a single huge one, so you can show whatever packages you need depending on what you need to see in each wiki page.

I would say it's better to encourage people (the package authors, or
other motivated individuals) to create HOWTO pages (a la OpenWrt) that
do a good job of describing the package. We can then link to those
articles from a top-level HOWTO pages.

I personally don't see that as exclusive things, both have their uses, the table of packages and what you say here.

Imho only way to do what you said is to make a "how to make packages" tutorial where you state how we want packages to be. Of course it won't be a rule (as we can't enforce anything over OpenWRT package repositories), but will encourage them as you say.

I'd like to take the guy in this PR here as an example of how packages should be in a perfect world.

His package is integrated with uci system settings, and he also wrote a pretty good README, see here

I will confess that I don't fully understand the Architecture
descriptions, but I don't see the use case for those pages. (Maybe I
just need to read more carefully...)

I see you, and raise you by stating that I don't see the point of having wiki pages for architecture at all, that stuff should go in the ToH and stay there only. It's not exactly highly coveted information.