[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] New task: science-dataacquisition

Andreas Tille <tillea@rki.de> writes:

> On Tue, 9 Dec 2008, Chris Walker wrote:

> 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.
> >
> 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].


> 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.



[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: