On Tue, 9 Dec 2008, Chris Walker wrote:
Indeed. The big advantage of the wiki is the ease with which anyone can edit it and categorise things themselves
Could you please have a look at the WIki Changelog who actually did the last ten edits. (No, I did not checked, but I wild guess there are at best 2 out of ten if the page is older than 6 monthes.)
(my initial categorisations of the chemistry packages were rapidly improved by a real chemist for example).
Sure. I think the Wiki is a perfect tool for the *initial* work to find a reasonable set - especially if you are no specialist. That's why I'm in favour of starting with a Wiki and move this work to tasks files after a two to three monthes period. After this time the interest of people vanishes in practice anyway and it becomes a single persons playground - at least this is my observation for lesser popular Wikis than for instance WikiPedia and the hype about Wikis in general which was triggered by WikiPedia is not really justified if you look at the state of several Wikis thoroughly. The possibility that everybody can work on a piece of text does not mean automatically that everybody really does so.
Regarding the time saving aspect: The dataacquisition page took me about 15 minutes (the green entries only one minute, the othes costs some research on upstream websites). Do you think the Wiki can compete with this?No it can't. I really like the fact that the tasks pages can generate things like version information and homepage automatically.
... and bugs pages which are an important QA tool. As I promised there are more such tools to come - und you get all of them for free. You also seem to underestimate the profit we gain by having always the full package description on the tasks pages - and we do provide even up to date translations. It is not only the versioning information and homepage.
What the wiki can do, and the tasks can't do (at least not yet) is have sections and subsubsections and potentially some explanatory text. This allows you to group packages that perform similar tasks near each other - which makes it easier to ignore packages you aren't interested in. If you use metapackages, you end up having information spread across several pages - which just makes it harder to find. To take a recent example, if you knew engauge-digitizer could extract numbers from bitmap graphs, but it didn't do quite what you want, how do you find g3data? With the current implementation of tasks, you would have to look through a dozen or more other packages in the dataacquisition task to find it[1,3]. With subsubsections, the packages would be next to each other in the list.
I agree that categorising (=subsections) is a good thing in principle -
but you always have to keep in mind what purpose or categorisation
should serve: We want to give our users quick access to the packages
that might be interesting for them. We will fail to do so if we
a) Force the user to understand a complicated categorisation
system (chances are really high that a random user will have
a different categorisation in mind than we have).
b) Hide programs in a deep categorisation tree. This is not better
than the flat non-categorised package pool.
That's why I'm not in favour of layers of metapackages but have only
a single layer. The fact that until now nobody has sended me a patch
to blends-dev in my eyes is a prove that there is nobody out there who
regards a deeper structure in metapackages as important enough to spend
some time on it.
Before we had metapackages and tasks pages people were forced to
browse the whole package pool for descriptions - and they probably
failed to do so (6 monthes ago I was seeking for a digitiser like
engauge-digitizer and g3data - but failed to find it). Now we have
metapackages and you have to browse a list of order 10 (compared to
a list of order 10000 in the flat package pool). That's an enhancement
of three orders of magnitude. Now you are asking to stretch the
concept farther? I'd call this overkill. If people are not willing
to read the really shortened list (while perhaps learning about
some other packages they might be interested in) IMHO they do not
deserve our work. And so they do not really deserve your manual
Wiki editing.
In an ideal world, I think we should be able to generate something like https://help.ubuntu.com/community/UbuntuScience#Physics automatically - with an option of long description or short description (to make it easier to scan down the entire list)[4].
Well, I admit I'm not really impressed by the URL above. IMHO what we provide on the tasks pages is better. If you want to generate a shortened List with only short descriptions - well, that's cheap. Could be a simple "wishlist bug" (the webtools are not (yet) in BTS, but I can put this on my todo list). It would be simple to create a page per Blend which lists all the short descriptions with homepage links and #task anchors. If it is this what you want to convince you to start on working on physics tasks files - it would not cost me much work to convince you. ;-))
[3] The Ubuntu list also mentions a third package in that category - "Plot Digitizer - A Java program used to digitize scanned plots of functional data. " I don't think it is packaged for Debian, and don't know how it compares with the other two.
Added as prospective package (at least in my local repository - I have
currently problems accessing the central repository ;-(). This revealed
even a drawback of the Ubuntu page you were quoting: If they would
provide a link to the package I would have been able to give some more
information like a link to an "inofficial" package - so the Ubuntu
page does not really serve as an example for my taste.
And now back to the statement: Keeping the Wiki up to date is so easys.
Please do not tell me that working on the dataacquisition tasks page
was not easy. People have thrown in mails with suggestions and the
things have shown up. Well - it was some work for me but not much and
user input was possible as well. We have also a certain amount of people
who have access to the tasks files in svn - so the barrier is not very
high.
Maintaining the tasks files is keeping the minimum information on
one central place to gain as much profit from it automatically.
Maintaining a "competing" Wiki page is doing manual work for less
information with the constant danger of beeing outdated for the
small advantage of slightly more flexibility in the content and
having the chance (but not the real effect) to involce more people.
You also forget that problems in the packaging (like missing Homepage
fields, broken descriptions, etc.) remain hidden and you are thus
wasting the chance for other QA features.
Kind regards
Andreas.
--
http://fam-tille.de