View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003802 | Scribus | Round Table | public | 2006-05-10 23:09 | 2012-06-18 20:16 |
| Reporter | avox | Assigned To | cbradney | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0003802: Expert Comittees | ||||
| Description | This meta issue is to discuss which other meta issues (round tables, expert groups) we need to discuss all thos RFEs. | ||||
| Additional Information | QUESTION FROM CBRADNEY: Sounds interesting. What would be the format of the communication of these groups? ML? Forum? Wiki? etc? ANSWER FROM CHRISTOPH_S: We haven't discussed this yet. Wiki sounds good and also ML, but it could also happen less formal, via email, as long as the right persons know about each other. I think we have to think about it a bit more. As I wrote, it's not necessary now, and perhaps not any time soon, but when it becomes necessary, it would be good to be prepared. MHANSKI'S PROPOSAL BASED ON PREVIOUS MAIL EXCHANGE: I would suggest to divide the steps to be taken into two parts: the short term measures (the part we discussed and agreed upon with avox and Christoph) and the long term measures (Christoph last proposals): I.PROPOSED SHORT TERM MEASURES (TO BE TAKEN NOW) 1. Creation of metabugs for future reviewers, e.g.: ----- christoph_s' comment: Is it possible to create a new category for metabugs in Mantis? That way, people who want to file a bug report could be advised to quick-check metabugs first. ----- - Usability experts - Typography experts - GUI experts - FreeBSD experts - Cheerleaders - Your proposals ----- christoph_s' comment: We need to carefully create the groups and select their tasks: not too many, but enough. I think this needs some further discussion ---- 2. Addressing the mailing list and asking for volunteers: - they should join the metabug groups by clicking on "Monitor" This a task for a Scribus team member 3. Writing 2 howtos for the wiki about: - how to report bugs (we need this one) - how to review bugs Me, Christoph, Johannes, Plinell? ------ christoph_s' comment: I'll try to do the first one tomorrow. This is no promise, though ;) ------ 4. Proposed tasks of the 1st contact group (updaters): - adding incoming RFEs to the group metabugs (new relations) - immediate termination of obviously wrong RFEs - removing of resolved relations from the group metabugs - monitoring the metabugs for confirmed and recommended issues ----- christoph_s' comment: The results need to find their way to the roadmap somehow, as Peter suggested. This is the job of the developers, since they can decide best what is feasible. ----- 5. Proposed tasks for reviewers: - bug validation and confirming - reviewing RFEs and discussing their viability (basically, what Christoph and Louis have been doing for the last month:) - recommending or disadvising the implementation to the Scribus team ----- christoph_s' comment: I don't think the last point is important, the guys are mighty slim ;) They will be able to figure out themselves. What would be more important, is giving the metabugs a structure, maybe in form of a written status report. Also, the attempt of the GIMP team to establish this kind of workflow failed miserably! ----- 6. New tab in Help/About for all these volunteers: Proposed names: "Quality assurance" "Bug busters" "Bug squashing squad" Your proposals ------ christoph_s' comment: What about a menu entry in the "Help" menu: Report a bug or submit a request? We now have the code for the use of an external browse. The link could lead to the Mantis login window. ------ II. PROPOSED LONG TERM MEASURES (BASED ON CHRISTOPH'S PROPOSALS) To be taken after after the reviewer teams have gathered some experience Short explanation: the bugtracker has two major weak points: -- the plentitude of - often contradictory, more often out of context - RFEs refering to the same areas -- resolving as duplicate often dumps valuable input Our reviever teams could be encouraged to: 1. Gather all RFEs relating to the same area 2. Discuss them wherever they want to discuss them (IRC?) 3. Close them all and create a new substitute RFE based on their synthesis ------ christoph_s' comment: 3. might not be necessary if we had a metabug category. Oh, and while I am at it: metabugs should be editable only for members of the reviewer teams to reduce the traffic. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
I copied the latest email from this discussion to this new issue and created a new category "Round Table" for future meta issues. |
|
|
Two areas of "expertise" haven't been mentioned yet: scripting and documentation. |
|
|
This all sounds okay to me, I'm not sure what it really gives more. One point I don't really agree on is this one: "Close them all and create a new substitute RFE based on their synthesis" I'm not sure this is a good idea at all. Closing them completely to me sounds a bit drastic, and it doesn't ensure the ideas are translated well, or mixed well neither. |
|
|
Instruction on bug reports is up: http://wiki.scribus.net/index.php/How_to_file_a_bug_report |
|
|
>>> This all sounds okay to me, I'm not sure what it really gives more. A better structured discussion, less bug reports (hopefully), once the procedure is established. >>>One point I don't really agree on is this one: "Close them all and create a new substitute RFE based on their synthesis" >>>I'm not sure this is a good idea at all. Closing them completely to me sounds a bit drastic, and it doesn't ensure the ideas are translated well, or mixed well neither. Agreed. It is the intention of the new discussion process to generate less bug reports, and especially less duplicates, not to raise new obstacles. It will be the job of the group members to educate people on the ML, the Wiki, IRC etc. |
|
|
This all sounds very reasonable. I put the rest of my ideas on the ML. |
|
|
the response of the mailing list wasn't overwhelming, so I would suggest to progress slowly with the creation of the first "expert group" metabugs and see whether we can encourage anybody to join them. I would start with "Typography experts" as an obvious candidate first and fill it with unresolved bugs/RFEs from this area. Is it OK with you? |
|
|
christoph_s: I'm a little confused now: is this "Usability" metabug of you intented to work independently of the "expert" metabugs? |
|
|
I have added a metabug for usability. Metabug page on the Wiki is up: http://wiki.scribus.net/index.php/Metabugs |
|
|
Needed next: PDF export, drawing, typography, text import, image import, vector import, image frames, text frames, tables, printing ... |
|
|
>>>I'm a little confused now: is this "Usability" metabug of you intented to work independently of the "expert" metabugs? It's a first step to give a structure to the mountain of bugs. It will make it easier for newbies and experts alike to indentify prior filings with similar content. IMHO, this is independent of any group of people who will discuss things in the future, it is about easier access. |
|
|
Christoph: it seems to me, it would only confuse users, if I started to create "expert" group metabugs, which had been discussed as part of the workflow for bug reviewers, with the same names as your "structure" metabugs. |
|
|
>>> Christoph: it seems to me, it would only confuse users, if I started to create "expert" group metabugs Maciej, "expert" metabugs don't make much sense, since it is hard to decide what an expert item is and what not. If we'd do that, it would become _really_ complicated. We must not forget the purpose of this exercise: to reduce the number of unnecessarily filed reports and a better structured discussion. Creating metabugs by item is much easier to achieve and to maintain than metabugs for different target groups. If we create metabugs for groups of issues (e.g. PDF), we can tell the people: Check the metabug first, then contact group x,y,z (and we haven't groups yet and most likely won't have in the near future), make a proposal, let it be discussed, and then a bug can be filed. This is totally independent of the structure or the content of metabugs. And finally, who are we to decide who is an "expert" and who not and who may therefore not file a bug or leave a comment? |
|
|
<quoting>Maciej, "expert" metabugs don't make much sense, since it is hard to decide what an expert item is and what not.</qouting> Disagree, it wouldnt't be hard at all, please see the description in "Additional Information". Every unresolved "Usability" issue would go into "Usability experts" as "ChildofRelation", the only difference to your metabugs would be, that you include solved issues too. <quoting>If we'd do that, it would become _really_ complicated. We must not forget the purpose of this exercise: to reduce the number of unnecessarily filed reports and a better structured discussion. </quoting> The main purpose I've thought of is to get more people into valitating bug reports and review RFEs. <quoting>... we can tell the people: Check the metabug first, then contact group x,y,z (and we haven't groups yet and most likely won't have in the near future)...</quoting> those "groups" were the experts metabugs, I don't have the impression we'd decided not to have them. In fact, we've hardly even started to discuss them. <quoting>And finally, who are we to decide who is an "expert" and who not and who may therefore not file a bug or leave a comment?</qouting> We wouldn't decide anything, this must some misinterpration. Those guys who would like to be notified about new "Typography" issues would click on "Monitor issue" and get notified every time a new relation is created. As easy as that. I'm against any obstacles to filing new bugs, the bug tracker should remain open by any means. |
|
|
>>>Disagree, it wouldnt't be hard at all, please see the description in "Additional Information". Every unresolved "Usability" issue would go into "Usability experts" as "ChildofRelation", the only difference to your metabugs would be, that you include solved issues too. Yes, because this will prevent bugs from being re-filed. I think it's necessary to have a record that's as complete as possible. Moreover, some issues may have already been discussed at length in one of these reports. >>>The main purpose I've thought of is to get more people into valitating bug reports and review RFEs. I think the main purpose is to become more efficient, which will make discussing issues easier and probably attract more people. As it stands now, one needs a pretty good memory to remember what was discussed in which report. >>>those "groups" were the experts metabugs, I don't have the impression we'd decided not to have them. In fact, we've hardly even started to discuss them. I didn't state that we decided not to have them. Fact is, we _don't- have them right now, and they probably aren't necessary at the moment, though this may change. >>>We wouldn't decide anything, this must some misinterpration. Those guys who would like to be notified about new "Typography" issues would click on "Monitor issue" and get notified every time a new relation is created. As easy as that. I'm against any obstacles to filing new bugs, the bug tracker should remain open by any means. Agree. I assume I misunderstood. |
|
|
just my 2c: keep it simple, please. It sounds too much bureaucratic and complicated to me. (hehe, remember that punk's not dead;)) |
|
|
Christoph: I understand what you are up to. Considering the admirable effort you've already put into your solution, I can only encourage you to progress. Once it works, we will see, if we can establish (if needed at all) some workflow for reviewers on top of it. Petr: Punk's not dead, it just smells funny :) At least Frank Zappa would put it this way. Joking aside: the current status is not simple, neither for submitters, nor for bug trackers. Your proposals to make it simpler are very much welcome. |
|
|
TBH, with all due respect, all I can see here is grouping of bugs, which are otherwise grouped by their category, and a LOT of emails generated for no reason. IE, 60 emails in 3 hours tonight. The team is losing focus on the bugs due to all this excessive grouping. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-05-10 23:09 | avox | New Issue | |
| 2006-05-10 23:11 | avox | Additional Information Updated | |
| 2006-05-10 23:12 | avox | Status | new => acknowledged |
| 2006-05-10 23:14 | avox | Note Added: 0011212 | |
| 2006-05-10 23:21 | avox | Additional Information Updated | |
| 2006-05-11 00:09 | christoph_s | Note Added: 0011219 | |
| 2006-05-11 11:39 | mhanski | Additional Information Updated | |
| 2006-05-11 14:07 | PLucAuclair | Note Added: 0011232 | |
| 2006-05-11 18:45 | christoph_s | Note Added: 0011237 | |
| 2006-05-11 22:21 | christoph_s | Note Added: 0011242 | |
| 2006-05-12 11:58 | louisdesjardins | Note Added: 0011251 | |
| 2006-05-15 16:44 | mhanski | Note Added: 0011309 | |
| 2006-05-15 18:17 | mhanski | Note Added: 0011311 | |
| 2006-05-15 18:40 | christoph_s | Note Added: 0011312 | |
| 2006-05-15 18:44 | christoph_s | Note Added: 0011313 | |
| 2006-05-15 18:50 | christoph_s | Note Added: 0011314 | |
| 2006-05-15 20:43 | mhanski | Note Added: 0011317 | |
| 2006-05-15 21:02 | christoph_s | Note Added: 0011318 | |
| 2006-05-15 21:32 | mhanski | Note Added: 0011320 | |
| 2006-05-15 21:49 | christoph_s | Note Added: 0011321 | |
| 2006-05-16 07:21 | subik | Note Added: 0011322 | |
| 2006-05-16 08:17 | mhanski | Note Added: 0011324 | |
| 2006-05-18 20:11 | cbradney | Note Added: 0011365 | |
| 2012-06-18 20:16 | cbradney | Status | acknowledged => closed |
| 2012-06-18 20:16 | cbradney | Assigned To | => cbradney |
| 2012-06-18 20:16 | cbradney | Resolution | open => no change required |
