Mantis Issue Tracking for Scribus
· Hosting provided by Anduin.net / Øverby Consulting ·

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003802ScribusRound Tablepublic06-May-11 01:0912-Jun-18 22:16
Reporteravox 
Assigned Tocbradney 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003802: Expert Comittees
DescriptionThis 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0011212)
avox (administrator)
06-May-11 01:14

I copied the latest email from this discussion to this new issue
and created a new category "Round Table" for future meta issues.
(0011219)
christoph_s (administrator)
06-May-11 02:09

Two areas of "expertise" haven't been mentioned yet: scripting and documentation.
(0011232)
PLucAuclair (reporter)
06-May-11 16:07

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.
(0011237)
christoph_s (administrator)
06-May-11 20:45

Instruction on bug reports is up: http://wiki.scribus.net/index.php/How_to_file_a_bug_report [^]
(0011242)
christoph_s (administrator)
06-May-12 00:21

>>> 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.
(0011251)
louisdesjardins (developer)
06-May-12 13:58

This all sounds very reasonable.

I put the rest of my ideas on the ML.
(0011309)
mhanski (developer)
06-May-15 18:44

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?
(0011311)
mhanski (developer)
06-May-15 20:17

christoph_s: I'm a little confused now: is this "Usability" metabug of you intented to work independently of the "expert" metabugs?
(0011312)
christoph_s (administrator)
06-May-15 20:40

I have added a metabug for usability. Metabug page on the Wiki is up: http://wiki.scribus.net/index.php/Metabugs [^]
(0011313)
christoph_s (administrator)
06-May-15 20:44

Needed next: PDF export, drawing, typography, text import, image import, vector import, image frames, text frames, tables, printing ...
(0011314)
christoph_s (administrator)
06-May-15 20:50

>>>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.
(0011317)
mhanski (developer)
06-May-15 22:43

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.
(0011318)
christoph_s (administrator)
06-May-15 23:02

>>> 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?
(0011320)
mhanski (developer)
06-May-15 23:32

<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.
(0011321)
christoph_s (administrator)
06-May-15 23:49

>>>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.
(0011322)
subik (manager)
06-May-16 09:21

just my 2c: keep it simple, please. It sounds too much bureaucratic and complicated to me. (hehe, remember that punk's not dead;))
(0011324)
mhanski (developer)
06-May-16 10:17

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.
(0011365)
cbradney (administrator)
06-May-18 22:11

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.

- Issue History
Date Modified Username Field Change
06-May-11 01:09 avox New Issue
06-May-11 01:11 avox Additional Information Updated
06-May-11 01:12 avox Status new => acknowledged
06-May-11 01:14 avox Note Added: 0011212
06-May-11 01:16 avox Note Added: 0011213
06-May-11 01:17 avox Note Added: 0011214
06-May-11 01:18 avox Note Added: 0011215
06-May-11 01:20 avox Note Added: 0011216
06-May-11 01:21 avox Additional Information Updated
06-May-11 01:22 avox Note Added: 0011217
06-May-11 01:23 avox Note Deleted: 0011213
06-May-11 01:23 avox Note Deleted: 0011214
06-May-11 01:23 avox Note Deleted: 0011215
06-May-11 01:24 avox Note Deleted: 0011217
06-May-11 01:24 avox Note Deleted: 0011216
06-May-11 02:05 christoph_s Note Added: 0011218
06-May-11 02:05 christoph_s Note Deleted: 0011218
06-May-11 02:09 christoph_s Note Added: 0011219
06-May-11 02:10 christoph_s Note Added: 0011220
06-May-11 02:10 christoph_s Note Deleted: 0011220
06-May-11 10:21 christoph_s Note Added: 0011231
06-May-11 13:39 mhanski Additional Information Updated
06-May-11 16:07 PLucAuclair Note Added: 0011232
06-May-11 20:45 christoph_s Note Added: 0011237
06-May-11 22:26 christoph_s Note Deleted: 0011231
06-May-12 00:21 christoph_s Note Added: 0011242
06-May-12 13:58 louisdesjardins Note Added: 0011251
06-May-15 18:43 mhanski Note Added: 0011308
06-May-15 18:44 mhanski Note Added: 0011309
06-May-15 18:45 mhanski Note Deleted: 0011308
06-May-15 20:17 mhanski Note Added: 0011311
06-May-15 20:40 christoph_s Note Added: 0011312
06-May-15 20:44 christoph_s Note Added: 0011313
06-May-15 20:50 christoph_s Note Added: 0011314
06-May-15 22:43 mhanski Note Added: 0011317
06-May-15 23:02 christoph_s Note Added: 0011318
06-May-15 23:32 mhanski Note Added: 0011320
06-May-15 23:49 christoph_s Note Added: 0011321
06-May-16 09:21 subik Note Added: 0011322
06-May-16 10:17 mhanski Note Added: 0011324
06-May-18 22:11 cbradney Note Added: 0011365
12-Jun-18 22:16 cbradney Status acknowledged => closed
12-Jun-18 22:16 cbradney Assigned To => cbradney
12-Jun-18 22:16 cbradney Resolution open => no change required



Copyright © 2000 - 2013 MantisBT Team
Powered by Mantis Bugtracker