Debtags and Blends tasks pages

[Andreas Tille]

On Wed, 28 Jan 2009, Ben Armstrong wrote:

> A QA process to ensure that only "approved" debtags make it out to the
> users, governed by some official body (probably including both the
> debtags team and the team for the Blend itself).  I can see that for
> some Blends this might be quite important. For Debian Jr., I am not so
> sure.

OK, this clarifies things.  Actually we also face in other Blends
the situation that we (as in Debian developers) are coming more
from the admin side and users have a different view.  So a reasonable
interface for the users might be interesting not only for Debian Jr.

> Who do we want to "own" the problem of making this determination, the
> developers or the users themselves?

If we want to serve our users at best I completely agree that they
should have a word about this.

> The answer is probably a bit of
> both.  So how strict do we need the QA process to be?  If the QA team
> is made up entirely of developers, then this may be a barrier for user
> participation.

Well, it is not really that way.  I tried to get users involved in our
mailing list - but I can not say that it is really successful and
specifically in the Debian Jr. case this will most probably not work
at all.  So definitely yes for user involvement - but a better way
of communication is needed.

> That is, if there is sufficient delay between a user
> making a recommendation and the recommendation becoming publicly
> visible, the user might lose interest in the excercise and stop
> contributing.  If the barrier for participation in the recommendation
> process is lowered, we may end up with more people involved and
> ultimately, better quality choices because of it.

Just a rough thought: *If* we try to establish the tasks pages as
central entry point (I'm not sure whether this is an optimal solution
but for the moment I do not know something better) what about a form
field like "Which package would you like to add" or something like that.

> But maybe I'm wrong about this and the whole issue of QA is orthogonal
> with structuring our Blend to allow maximum input from users for
> package recommendations via debtags.

In principle DebTags works with a "form field" like I suggested above
so If we feed reasonable preseedings to the DebTags form we might use
this.  Than we might use a script that compares DebTags and tasks files
and offer the diff to the Blends team.  (This is in principle what I
had in mind when I wrote the initial mail.)  So we might be able to
get some user response if we try to interlock DebTags and tasks files.

The connection points might be:

   1. tasks pages generated from tasks files
   2. tasks page links to reasonable feeded debtags input form where
      user might tweak debtags
   3. Blend team uses script that parses a list of debtagged packages
      which are not yet in the tasks file / should not be there
   4. Blend team edits tasks files or fixes DebTags
   5. Goto 1.

Kind regards

          Andreas.

-- 
http://fam-tille.de