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

Re: Debtags and Blends tasks pages



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


Reply to: