{Discussion} Categories

[Little Girl]

Hey there,

Marc Kaplan wrote:
> Little Girl wrote:

[PageDiscussion pages being done away with or not]

> I am using the PageDiscussion pages more as a "Draft" page. I chose
> to call it PageDiscussion to allow for editing and input by
> additional people. Whether to call the page PageDiscussion or Draft
> can be left for a discussion at a later time. However, know that
> whenever any page that I recommend get officially implemented, the
> PageDiscussion (ie Draft in that case, will be emptied and either
> deleted or tagged for deletion, so as to not confuse future users.
> This will be done with Home/PageDiscussion and Teams/PageDiscussion
> on the Team Wiki after the launch on 10/30.

I'm glad to hear it, although you don't owe me any defense. I was
just checking to see if I'd misunderstood about those pages since
I've been busily removing links to them whenever I come across a page
that hasn't got a Discussion Page.

[CategoryDocumentation being done away with]

> I knew I had remembered us discussing removing
> CategoryDocumentation, but had missed it.  That does make this
> easier.

It will take a while, but eventually they'll all go in other
categories. I'm glad you're having a category discussion, though,
because I often come across pages that don't fit into the existing
categories, and I just leave those alone, which defeats the purpose.
Hopefully this discussion will lead to the creation of categories such
pages can go into.

> > The CategoryCategory page[3] is immutable, and doesn't show
> > CategoryProgrammingPython.
   
> I wonder if it has something to do with the Wiki code for the
> script. Actually, here is what I think happened, and if it is, this
> makes total sense on how things would go.
 
> I created CategoryProgramming.  Then, I created the Parent Page
> "Python" within CategoryProgramming and made each of the other
> pages articles under that parent.  In order to make the search code
> easier so that I could make them show up at once on the Python
> page, I put at the bottom of each article
> CategoryProgrammingPython.  These types of tagging code make it
> simpler to use Wiki Search code to create automatic listing and
> take full advantage of the software's capabilities.

Ah, okay, I had to do a bit of sleuthing to figure out what went
wrong, but I think I see it:

> I created CategoryProgramming.

CategoryProgramming[1] already existed.

> Then, I created the Parent Page "Python" within CategoryProgramming
> and made each of the other pages articles under that parent.

The Python[2] page ended up as a child of the Programming[3] page,
which already existed.

> In order to make the search code easier so that I could make them
> show up at once on the Python page, I put at the bottom of each
> article CategoryProgrammingPython.  

The CategoryProgrammingPython[4] page doesn't exist, but can be
created. The links at the bottom of the pages point to a nonexistent
page.

I guess the question to you would be whether you want the
CategoryProgrammingPython page created and whether you want the
Python page to remain as a child of the Programming page or would
rather have it be a child of the CategoryProgrammingPython page.

> > The one difficulty this will cause is that you may cause users to
> > have trouble finding what they need. I know it doesn't seem like
> > it when you first think about it, but the more complex you make a
> > structure, the more difficult it is to navigate. Not everyone
> > thinks the same way, so a name you choose for a category might
> > not be one they'd ever associate with $PROGRAM or $FUNCTION. If
> > they don't even recognize the subcategory as one they would
> > associate with what they're looking for, they may never look
> > there.

> > Playing devil's advocate and arguing against myself, the
> > flip-side is having categories that are broad and contain large
> > numbers of pages, which would also make it hard to find what
> > you're looking for. 

> I agree completely.  That is why articles can be in multiple 
> Categories.  Remember, these are not going to be the be-all,
> end-all. This is just for starters to help bring organization to
> chaos.  It can always be reevaluated and fine-tuned at any point.
> I think we have smart enough users to help us or point out glaring
> mistakes.

I think the beauty of wikis is in their exploded nature. The fact
that every page can stand alone and be gathered into other pages at a
whim. Where I think the trouble begins is when there are parent and
child pages, because then a hard structure is determined, and it
takes quite a bit of effort to undo that structure if a new structure
is wanted. Categories are a brilliant solution to that, in that you
can group similar pages by category (and, as you said, in multiple
categories), and instantly regroup them a different way if you like,
without having to change their hard structure in any way. Rather than
downplaying the usefulness of categories in any way, I feel that
they're a wonderful way of getting an instant overview of exactly
what's there and what could/should be done with it. Hopefully
the result of this discussion will be a sensible category selection
that makes it easy to decide which category any page fits into.

[Removing CategoryEvolution]
   
> Then let's do it.  I removed the CategoryPython.  To remove a
> category from the search, simply remove the tag for it a the bottom
> of the page.

It's done. I changed all the CategoryEvolution links on the Evolution
pages to CategoryEmail and tagged CategoryEvolution for deletion.
While we're on this topic, there is CategoryOffline[5], which
contains pages on offline package management. All of the pages also
have the CategoryPackageManagement[6] tags. Since all of those pages
have to do with Package Management, are there any objections to my
removing the CategoryOffline tags from them and tagging the
CategoryOffline page for deletion?
 
> >> I see no reason to distinguish, via category, whether something
> >> is "Commerical" or "Third-party".  This can be done by link the
> >> appropriate article to the appropriate "Parent" if needed.

> > You could also, instead, create a Commercial or Third Party tag
> > that can be placed on any page containing commercial or third
> > party software. Since commercial or third party software performs
> > similar functions as free and open source software, it's logical
> > that one would find it in the same category/categories as free
> > and open source software, since those are categorized by their
> > functions. 
   
> I think a "Tag" on the article or section would be a good idea.
> But it could also fall under the "Unsupported"

Whatever you guys decide is fine. (:

> >> Now, here's a tricky one: PackageManagement.  I see no reason it
> >> could not be under 2 categories, such as: CategorySoftware and 
> >> CategoryMaintenance (something similar).

> > Package Management is something that comes up often when using or
> > discussing Linux. To new users who have not used Linux before,
> > package management is a new concept. As such, it's something they
> > are likely to look for specifically when they see it mentioned
> > elsewhere. You might want to keep that category. You also might
> > want to rename it to CategoryPackage, so that no matter how a
> > search is done (packages, package management, etc.) the page will
> > be found.
   
> My point is, PackageManagement should be an article, not a
> Category. Determining which Category to put it under, that's the
> problem.

It's too big. There are 22 pages in the category already, and a few
more that might fit into it. I suppose you could concatenate all the
information into one useful page which could go into another category,
but that might be a pretty big job. (:

> >> Another example of separation might be, instead of having 
> >> CategoryXWindowSystem, we might want CategoryDesktopManagers, 
> >> CategoryFileManagers, CategoryWindowsManagers, etc.... These
> >> would include items like GNOME, K, xfce,Thundar, Nautalius,
> >> accordingly..... This would be a great way to
> >> categorize/organize, and help newbies on the differences of each
> >> and how they can work on customizing Ubuntu to be their own.

> > On this topic I feel that simplification is best. CategoryDesktop
> > would be a simplified category that would nicely capture all of
> > those, and is something the average user would be likely to look
> > for. 
   
> Simplifying it under Parent Pages would, agreed, make things
> better. But I would actual take it one step further by calling it 
> CategoryDesktopManagement, or CategoryDesktopCustomization.  I
> think CategoryDesktop would make that way too broad.

True. Of the two, I vote for CategoryDesktopManagement.

> > In my travels throughout the wiki, I've found a few immutable
> > pages I'd love to edit, but can't. One example is the
> > CategoryCategory page[3]. The text at the top of that page is:

<SNIP>

> > Do you see the error? I see it, but I can't fix it.
   
> If you check the PageHistory, you'll see that CategoryCategory has
> never been edited.  This is a static Wiki page built into the
> code.  To get wording like that to be changed, I think it might
> even have to go to the MoinMoin developers, not just ours.  I would
> suggest submitting it as a bug through Launchpad.

Yep, Matthew East's message lead me to the Moin wiki, and theirs has
the same error, so I'll file a bug report with them.
 
> > My suggestion is:

<SNIP>
   
> Based on this thought process, it sounds like we have two different
> type of Software Categories:
 
> Applications and Productivity
 
> * Games
> * Graphics
> * Internet
> * Office
> * Sound & Video
> * Education
 
> - and -
 
> System Settings and Configuration
 
> * System
> * Debian
> * System Tools
> * Settings
> * Universal Access
 
> In all honesty, I don't think the second set of menu items actually
> should fall under "Software", but rather some type of
> CategorySystem.

CategorySystem is nice and broad, and can hold quite a bit of
content. I definitely like that one as an addition to the existing
categories. And following your method of creating subcategories, you
could have CategorySystemSettings, CategorySystemTools, etc. all
under that same main category.

>  Reagrding the FAQs, as I have mentioned in the past, I am trying
> to work with QA and the development team to get the Hardware
> documentation away from the wiki into a more centralized and
> organized location.

I suspect that a MySQL database would be the ideal solution with a
PHP interface for visitors to use to add to it. The clumsiness of
editing an existing wiki table when you have no experience with wiki
is probably preventing quite a few people from adding their hardware
information to what's already there. A simple question and answer PHP
page with pull-down menus would make that a more appealing process.
I've got an example of such a thing if you're interested.

[1] https://help.ubuntu.com/community/CategoryProgramming
[2] https://help.ubuntu.com/community/Programming/Python
[3] https://help.ubuntu.com/community/Programming
[4] https://help.ubuntu.com/community/CategoryProgrammingPython
[5] https://help.ubuntu.com/community/CategoryOffline
[6] https://help.ubuntu.com/community/CategoryPackageManagement

-- 
Little Girl

There is no spoon.