Hi Christoph, actually, I agree with most of what you said from a perspective of the blog only. If you look from a global perspective with the lxde blog, wiki and website being part of a global content cloud defined by keywords, tags, categories, links, content itself etc things might look differently.
Concerning tags, using tags even once is ok to my mind. I use them extensively. They simply make it more likely to get related searches to the LXDE blog. And, I do not see tags related to one blog only. If a tag only appears once on the LXDE blog, but at the same time at other blogs as well, some social web services can offer tag clouds for example. There are also other ways to do this, but this is one way. There will be more ways to search this way, e.g. "Search all FOSS blogs for the tag 'LXDE". Don't we want to appear in the search results here? So, looking from this perspective I find it very useful even to have a tax lxmusic 0.4.3 for documentation purposes. On Technorati there is the search option "Search for tags" which I sometimes use. Therefore the tag "LXDE" also makes sense and I would even argue to tag every post with "LXDE". Also, as I observe nowadays many people who are looking for information tend to search for "keywords" instead of searching top down like in categories. Extensive tagging also makes sense in this regard. What do you think? - Mario On Tue, Mar 23, 2010 at 3:31 AM, Christoph Wickert <[email protected]> wrote: > Hello LXDE people! > > We should do some cleanup of the wiki and the blog. Some people tend to > introduce new useless categories (in the wiki) and tags (in the blog): > They introduce more redundancy and thus make info harder to find for the > users. For the writers it is more complicated to manage the wiki and the > blog. > > So I suggest some guidelines: > > * Do not use Categories (wiki) or tags (blog) if they will > propably never have more than one entry. For example the tag > "lxmusic 0.4.2" is useless because it is very likely that there > will be only one blog article about lxmusic 0.4.2. If you want a > tag, use "lxmusic" instead and apply it to all articles that > mention lxmusic. > * Do not use redundant names: Do not duplicate LXDE in the > tag/category, e.g. just "Community" or "Development" instead of > "LXDE Community" or "LXDE Development". It's clear that the LXDE > wiki will not deal with KDE development. Don't worry about > search engines, they will find us anyway. > * The category "LXDE" is the most useless category but contains 56 > articles. What are we going to to with it? > * To remove a category from the wiki, first empty it by removing > the category from the wiki pages and then make a redirect from > the removed category to the proper one, e.g. from "Category:LXDE > Development" to "Category:Development". This is done with > "#REDIRECT [[name of the target page]]" > * Categories should start with capital letters. Not sure about > tags in the wiki though, but we should make sure that we don't > have the same tag with capital and lower case letters. > * Last but not least: When you edit the wiki, please add a small > note for the changelogs. > > Does everybody agree to these guidelines? If so, we should agree on a > basic set of categories for the wiki and make sure that every wiki page > is at least in one of them. > > Suggestions for categories: > * Components (not "LXDE Components"!) > * Community > * Development > * Distributions > * Events > * FAQ > * GSoCc (or "Google Summer of Code" but not both!) > * GSoC1009 > * GSoC2010 (or "Google Summer of Code 2010" but not both!) > * HowTo > * Press > * Projects (as starting point or people who want to get involved, > otherwise kill it) > * Translations (better "Localization") > * Website > > The rest of the categories IMO is usless. See > http://wiki.lxde.org/en/Special:Categories for a full list. > > Comments, thoughts, rants? Just let me know. > > Regards, > Christoph > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
