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 -- To UNSUBSCRIBE, email to debian-custom-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org