-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brad Fuller wrote:
> ico@email-addr-hidden wrote:
[..]
> What's hard about registering? You do it once,
> firefox takes care of your password and your done.
AFAIR the discussion got started due to requiring a valid email address
for registration. username/password/privacy is a different issue.
>
> Again, I don't think registering will deter those who want to
> contribute. On the flip side, w/o registering opens up a whole lot of
> potential vandalism.
agreed. There are alternatives but no quick'N'easy(TM) solution in
sight. I don't want to return to the auth-discussion. Can I sum it up as:
We can manage to set up a simple but effective system to:
- - restrict [media] upload and admin-capabilities to trusted users
(editors, LAD, LAU members, sign off strategy, ..)
- - limit anonymous edits to a minimal amount of SPAM while not annoying
anon. users. this will be an ongoing battle and we can discuss,
experiment and improve.. (CAPTCHA, timed IP locks, limit # of pages per
user,...)
> I don't know why wikipedia would deny the proposal because of
> information changing. Why don't we ask them.
>
> Wikipedia is a great place to do this because of it's visibility.
>
exactly. but most of the wikipedia entries are rather patchy with
details! A framework like arxiv.org is not really suitable for
linuxaudio.org either. although it would be nice if doc.linuxaudio.org
will provide SGML & docbook processing capabilities.
IMO diversity is a good thing. and I'd be surprised it linuxaudio will
only fragment to into 2 or 3 wiki installations worldwide! interwiki and
perma-links are already quite common, and with feeds, data import/export
plugins, etc information spreads. nevertheless linuxaudio.org should
become the site of choice for linux sound collaboration and claim some
authority!
Let's focus on user interface and templates.
democracy and taste won't match: I'll vote for a two column layout + a
(static/fixed?) top bar. (similar to wikipedia). It would be nice if
there were linuxaudio color & icon themes, but that's for later..
in the "menu column": list a handful of (constant) links +
wiki-commands; and a generated list of "quick-links" related to the
current page (category, tags,...)
The "main column" displays either a custom wiki page (doc.linuxaudio.)
or (for apps.linuxaudio.org) a fixed-layout, generated from Meta-data:
ie: info-pages, category lists.
IMO both doc.. and apps.. should make use of the same category system
and maybe even share the page-source for the title+abstract page.
- -> the apps.. will be a side product of doc..
here's a set of meta-tags that each doc. would need to provide on it's
title page:
1 req: TXT: title / name
2 req: TXT: description / abstract
3 opt: TXT: Author
4 opt: URL: screenshot, icon, banner
5 opt: TXT: version_string, release_date
6 opt: URL: source_repository (cvs,svn,darcs,.. URI)
7 opt: URL: website
8 req: TAG: one or more category tag(s).
discuss:
1. use wiki page name as title
3. also author email, license, etc. ?
4. allow multiple screenshots? screenshot_00, screenshot_01,..?? videos?
7. maybe use different URLs for: url_web, url_doc, url_src, url_other
I vote for a minimal set of meta info: 1,2,4,8 (+7) - other key&values
can get very specific and result in possibly inconsistent assignments ->
use custom wiki pages. For properly marked up documentation there's docbook!
a couple of ideas to generate the app listing:
- - generate lists with and without screenshots/banners/logos/abstract
- - each entry has at least a title and a link to doc.linuxaudio.org
-> wiki-title-page
- - optionally link directly to web-page, documentation or download ??
- - present a "related category" link list in the menu-column.
- - merge (sub-)categories in view.
- - browse or search
* search for a keyword
* selecting multiple tags from a tag-cloud.
* pager: next/prev, related categories, history trace, breadcrumbs
I suggest to use twiki, mediawiki or dokuwiki for the job. I don't think
that wordpress will do as nice; it could. but in that case, it should
become blog.linuxaudio.org. There are certainly many possible
implementations: we should consider stability & robustness; long live @
low maintenance; flexibility & speed; KISS. personally I've had good
experience with dokuwiki. OTOH. mediawiki will allow copy and paste to
wikipedia, but we usually want inter-wiki links rather than dup entries.
aaah and the above mentioned top-bar can connect the different
*.linuxaudio.org sites, hold a title, banner, drop-down menu,...
you name it! keep up the relentless flow of discussion and
nourish the advocatus diaboli in you. if your anger is not yet focused,
go and play your neighbors a series of tritoni for half an hour.
I'm sure we can come up with with a clean layout and icons for
visualizing meta-information after that. one could go as far as to
assign symbols to major-categories or design a children's look&feel
template for the title page(s). It'd be cool to have another prototype
wiki by January, but the final product should aim for quality and it's
yet too early to set a deadline. maybe the LAC2007 can provide a
platform for discussion and promotion.
#robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFg3fweVUk8U+VK0IRAroKAJ9+HhVq1FoMxB020YYOds/skZ5PggCguioF
wVoE/ksHnNtze2S8Kqm+n04=
=i009
-----END PGP SIGNATURE-----
Received on Sat Dec 16 08:15:02 2006
This archive was generated by hypermail 2.1.8 : Sat Dec 16 2006 - 08:15:02 EET