Re: [RFC] New task: science-dataacquisition
Andreas Tille <tillea@rki.de> 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 :-).
Reply to: