[ubuntu-art] Organizing Artwork Wiki

[Thorsten Wilms]

On Sun, 2009-04-05 at 10:03 -0400, John Baer wrote:

> IMO we should lay out and agree to the desired organizational structure
> of our pages and then move content to this structure.

I have to admit that after getting a general OK, I applied a just-do-it
approach without discussing each step ;)

Does wonders for getting stuff done, but is only as good as that one
person knows it :)


My guiding principals are:
- All required information in a concise manner
- No useless information and filler
- Avoid placing material of different scope on one level. For example, a
single proposal like WarningThemes shouldn't be on the same level as
Incoming ...

So far I made an exception for Breathe, though, as one might argue it
should be in Incoming. I don't dare to touch it without asking Cory
because he's Cory and think it deserves a little extra emphasis :)

My ideal is that a newcomer can start from Artwork (and easily get there
in the 1st place) and find all the info he needs, no matter if he starts
from basically zero, or if he is looking for something specific.

1st level shall be:
 * Official Artwork
 * Breathe Icon Set
 * Incoming
 * Documentation
 * Specifications
 * Meetings
 * Archives

Breathe is Cory's realm and clean.

Incoming has per release sub-pages and a few long-term, the chaos has
been moved to Incoming/Attic.

Documentation shall contain:
 * Artistic guidelines
   * Recommended reading on various subjects
   * Design Process
 * Licensing guidelines
 * Technical documentation
   * Recommended Software, including tips and links to tutorials
   * Theming
(not necessarily with these exact sub-pages)

Specifications is so meager it's tempting to dissolve it.


> Once this is in place we should monitor the "Artwork" branch to ensure
> new content is placed appropriately.

Yes, constant care.


> The desire of the following page is to assist with that effort.
> 
> https://wiki.ubuntu.com/Artwork/WikiDesign
> 
> Again, I suggest we design the desire solution, document, and then
> create tasks to achieve the agreed result.


Tasks:
 * Add info to the Artwork page (directly or linked) that allows a 
   newcomer to work with the wiki, even if they came with no prior 
   knowledge about wikis.
 * Add info to the Artwork page (directly or linked) that allows a 
   newcomer to join us on IRC, even if they came with no prior 
   knowledge about IRC.
 * Shape up the Software page in Documentation, such that someone who 
   has never heard of any of our tools will
   * find to them
   * be able to associate them with similar commercial tools,
   * understand what they do even if they didn't know what bitmaps 
     and beziers are,
   * have links to the finest tutorials
* Cover topics like color theory, composition, drawing in 
  perspective ... a few _high_quality_ links should do.
* Fill in the missing releases in Archives
* Collect definite info on Licensing, covering which exact licenses we 
  should use for what, and what we can and can't do with material that 
  has other specific licenses.


> One thing I noticed is wiki response time is not as good as it should
> be. A good example is the "WikiDesign" page.

Well, sometimes the wiki is fast, today it crawls. Still much better
than being unavailable like yesterday :)


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/