From Audacity Wiki
Revision as of 14:22, 23 July 2014 by James (talk | contribs) (Added info on wikis editable. Agree about announcement subscription.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Merging Tables

James 20Jul14 I'm toying with the idea of reducing the number of tables. We look very fragmented at the moment. The wikis are part of, so thinking of making the description of that site two column (containing the current info about the wikis). As for nearly all users the wikis are read only, the fact that they are editable wikis is now less relevant. They are just parts of the website. Does that seem logical? The announcement e-mail list link seems to be broken, and I think perhaps should be the first in the list of e-mail lists? So two tables fewer?

  • Gale 22Jul14: Not sure about merging the wikis table - it would make a longer table and then would be kind of odd to have the Forum as a separate table. At least the Wiki is user editable where is not. The h3 for "Wikis" could say "User-editable Wikis - ask for an account to contribute".

    The announcements subscription link isn't broken, except the ad banner makes it look so. It would probably be better to have the subscription box on its own page then link to that page. Been on my list do for a while.

  • James 23Jul14: Thanks. Feel free to revert/change the change I've made if you like. Announcement subscription is below the fold on my screen. Page of its own sounds good to me.

Advertising -quality list (July 2014)

Gale 20Jul14: Should we continue to hide the -quality list from this page? The list now has a Nabble archive. We don't want -quality used as a help resource but should we encourage new developers to subscribe to it in the same way we encourage them to subscribe to -devel?

If not then we continue with the current situation where "bug topics" started by a new developer on -devel are forwarded from -devel to -quality, then end up duplicated on both lists (or drift back to -devel only) because the new developer is not subscribed to -quality.

James 20Jul14: Done. Thanks for the suggestion.

Networking (July 2014)

Gale 19Jul14: FWIW I think the choice of word "networking" in the pre-TOC is a little misleading. Maybe it's a buzz word that I am not aware of, but it made me think of Ninjam or other online music collaboration which presumably will have security issues. "Collaboration" might be clearer, or at least used as an alternative word to repeating networking.

  • James 19Jul14: If you'd like to change it you are welcome to. Thanks for the other changes.
  • Gale 20Jul14: I'm fine with it as you changed it now to emphasise sharing, though it seems a bit verbose for skim reading. I just didn't care for networking as the headline word. I agree new sub-forums e.g. for podcasting would be good.
  • James 20Jul14: Yes, I agree it is too wordy. One solution is to have a new table about meet-ups (AU14, GSOC Mentor Summit 2008) and move (and change) the text about AU14 to it. Don't have time to do that at the moment. If I did, it would go under the forum table. Good solution?

Old fixed issues

Gale - I've received feedback that our current numerous websites, mailing lists, forums, IRC and wiki resources are confusing. Hence this attempt to put them all on one page. Intention is to make this a one stop shop for people to decide what they want to subscribe to. James 15:18, 10 December 2007 (PST)

James - fine, thanks. I might tidy this page a bit. Is this feedback "one-off" or have you seen a pattern? - Maybe the main site wants reviewing as well (possibly merging the Contact and Help tabs, so those resources are on the same page?).


PS do you know if adding class ="wikitable" and "id" and "legend" help screenreaders? Visually, it makes no difference if class="wikitable" is there or not (and the formatting seems the same either way).

Feedback = once-off, but was quite detailed and overall seems valid to me.

Thanks for the tidy up. Significant improvement.

class=wikitable makes a difference on the manual wiki, therefore if we did things right it could do here too!

id and legend I guess will help screenreaders, but it's only a guess. We need Leland on this!