Andreas Tille <[EMAIL PROTECTED]> writes: > On Tue, 9 Dec 2008, Chris Walker wrote:
[snip] > 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. Agreed completely - and that's roughly what I was hoping - initial categorisation is done on the wiki then it transfers to the tasks. [snip lots of stuff I agree with] > 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. I particularly agree with this. > > > 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. > > [snip] > > 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. Absolutely, I couldn't agree more. > 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. I've not yes found the time to do this - but one of these days... > > 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). <AOL> (well actually 12 months in my case, but...) > 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). Pretty please. > 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. ;-)) That is halfway towards convincing me. If you did that, and also provided a means of having subsections - by not sorting the packages at all (currently they are alphabetical), and having the ability to put in subheadings - not sure of an appropriate syntax, but something along the lines of: #heading "Condensed matter" # subheading "Diffraction" # Comment "Analysis and model fitting of X-ray diffraction data. Synchrotron users please note that ..." I'd definitely be convinced[1]. [snip] > > 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. Indeed. As a prototype, the wiki is great, but once there is consensus on a structure, keeping the data in one place is indeed far better. > > 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. It is the extra structure that I think is useful. I've been organising the wiki as a prototype structure useful until someone gets around to adding this facility to the tasks files. > 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. > Indeed. Chris [1] At this point, I'm going to keep very quiet about the fact that I've been trying to maintain the physics task too :-). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
