openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [PROPOSAL] Bugzilla Cleanup
Date Thu, 26 Jan 2012 20:23:46 GMT

On Jan 26, 2012, at 11:54 AM, Rob Weir wrote:

> On Thu, Jan 26, 2012 at 2:41 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>> 
>> On Jan 26, 2012, at 11:15 AM, Rob Weir wrote:
>> 
>>> On Thu, Jan 26, 2012 at 1:24 PM, Regina Henschel
>>> <rb.henschel@t-online.de> wrote:
>>>> Hi Rob,
>>>> 
>>>> Rob Weir schrieb:
>>>> 
>>>>> I'd like to make some changes to our bug tracker, to make it more
>>>>> user-friendly.  Since these changes are not easily reversible, I'd
>>>>> like to describe them first, to see if anyone has objections.
>>>>> 
>>>>> 1) Convert legacy language project "products" into "components" under
>>>>> the "native-lang" product.  I'll ensure that all existing bugs
>>>>> previously classified under a language project code are reclassified
>>>>> into the new structure.
>>>> 
>>>> 
>>>> +1
>>>> 
>>>> 
>>>>> 
>>>>> 2) Create a new "comitters" group in BZ, with additional permissions
>>>>> like "editbugs" and "canconfirm"  AOO committers will be added to this
>>>>> group, on request. I can't do it automatically, since your BZ login
>>>>> might be different than your Apache ID.
>>>> 
>>>> 
>>>> I do not like the term "commiter" here. BZ user with additional permissions
>>>> are more "quality assistant". And do they really need to be commiters with
>>>> Apache ID? I think not.
>>>> 
>>> 
>>> That was a request from Dave in another thread, that all committers
>>> should be routinely included in BZ with additional privileges.  It
>>> probably doesn't matter what the group is called, but I think we want
>>> a relatively simple, four-level approach:
>>> 
>>> Admins
>>> Foo
>>> Default Registered
>>> Unregistered
>>> 
>>> I'm flexible in what we call "Foo".
>> 
>> I was expressing an improvement over the current situation and was frustrated by
not having the right to close an issue I had fixed on the website.
>> 
>> I'm actually for three levels and permissive rights for everyone who is registered.
>> 
>> Admins (anyone on the PPMC, Infra, IPMC and Members who wants it)
>> Registered (anyone with a BZ account)
>> Unregistered
>> 
>> While this might open us up to people playing games on issues. If it happens we can
deal with it as a community issue. The more we enable the community to participate the less
are our needs to find volunteers to administrate something.
>> 
> 
> A huge -1 from me on that.  I don't think it is very wise to have
> 1,000's of anonymous accounts having permission that allow them to
> make irreversible and potentially damaging changes to our bug
> database. We don't do that anyone where else in the project.  Can you
> point to any other Apache projects that allow this?

Apache POI operates like that. Projects differ, I believe that most start as permissive. The
ones that are restrictive may become that way due to spammers, but that is only after persistent
efforts that make the BZ admins spend more time on the pain of fighting spammers vs. the pain
of adding users.

I would only allow administrators to delete an issue. All changes are already written to a
ML and abuse will be seen. The community can police itself here.

Now let's consider the users who are submitting bugs. The more that they are enabled the more
that they can be engaged. This includes active dissent about the status of an issue in the
tracker.

> 
> But I am happy to have a "trusted volunteer" group that we can add
> trusted volunteers to, on request, to give them additional
> permissions.

To me "trusted volunteers" *IS* anyone who signs up. It is trust but verify. Trust means the
community is as enabled as possible, verify means that all changes are subject to review.

I know that this is completely different from the many layers of project and assignment that
the OOo project had under Sun/Oracle. We are not that group, that division between developers
and the community should be completely blown out.

I've taken time to write this and the previous response because it was important to express
this POV at this moment. If I'm not responsive in defense for the next 48 hours, it will be
due to a need to get some other tasks done.

Regards,
Dave


> 
> 
>> Regards,
>> Dave
>> 
>> 
>> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> 3) Delete obsolete "products" like bizdev and council.
>>>> 
>>>> 
>>>> What will happen with the associated issues? Suggestion: A product "legacy"
>>>> with all of them under components. It should not be available in the form
>>>> for new issues, but only in advanced search. And all of their issues should
>>>> be "closed".
>>>> 
>>>> 
>>>>> 
>>>>> 4) Delete the permission groups associated with the removed products.
>>>> 
>>>> 
>>>> +1
>>>> 
>>>> 
>>>>> 
>>>>> 5) Remove default owners for components.   Most of this information is
>>>>> obsolete in any case, with owners being people no longer involved with
>>>>> the project.  This will be easy for any comitter to add back, if they
>>>>> want to volunteer to own issues in a given category.  But maybe we
>>>>> don't even want "owners"?
>>>> 
>>>> 
>>>> A "owner" is meaningful. But it should be that person, that is actually
>>>> working on that issue. You are right, that there need not to be default
>>>> owners for each component, but one default owner is sufficient something
>>>> like "untreated task".
>>>> 
>>>> 
>>>>> 
>>>>> 6) End result is a much flatter structure.  Instead of hundreds of
>>>>> different permission groups corresponding to 100's of different
>>>>> components, we have admins, committers, and users.  Admins and
>>>>> committers can modify all bugs, regardless of components.
>>>>> 
>>>>> 7) One objection might be, but what if we have a user who needs to
>>>>> regularly modify many bugs, to help move them through the workflow,
>>>>> someone who is helping us clean up bugs, correcting classifications,
>>>>> verifying issues for us, etc.  Won't they be locked out of doing this
>>>>> administrative tasks?  My response is simple:  We should be making
>>>>> such users into committers based on that level of contribution.
>>>> 
>>>> 
>>>> I disagree here. The only question is, whether she/he does a good job on
BZ.
>>>> For example identify duplicates, sort out support requests, collect missing
>>>> information. You should invite them, but do not set it as prerequisite.
>>>> 
>>> 
>>> We have other areas where non-committers are able to make
>>> contributions, whether via code patches, or as forum volunteers or on
>>> the wiki.   That's OK.  But where these contributions are consistent
>>> and high quality, we (the Project Management Committee) will offer
>>> these contributors the status of committer and PMC membership.  The
>>> committer side of it might not mean much if the person is not checking
>>> in code to SVN, but the PMC membership gives the person a formal vote
>>> in project-wide decisions, such as on releases.  We want good people,
>>> of all disciplines and project roles, involved in that part of the
>>> project oversite.
>>> 
>>>> 
>>>> I miss a cleanup of the "version" list box.
>>>> (1) Do not show developer versions, which are superseded be a released
>>>> version. But bundle them to one item, when the corresponding release is
>>>> done.
>>>> (2) The purpose of "version" is unclear for users. They tend to use it in
>>>> the kind "I still see it in version ...", although it has been planned to
be
>>>> "Bug was _first_ seen in ...". So the title should be enhanced.
>>>> (3) Show only actual versions in the form for new issues. A user should not
>>>> report a problem for a version, which will never have a bug-fix release.
See
>>>> https://issues.apache.org/ooo/show_bug.cgi?id=88964
>>>> 
>>>> 
>>>> Remove the field "priority". Reasoning: (1) Numbers do not tell whether a
1
>>>> has more priority than a 5 or the other way round.(2) Priority has no effect
>>>> in resolving. (3) Severity is enough for classification.
>>>> 
>>> 
>>> I saw that we had both severity and priority. I could not figure out
>>> how they related to each other.
>>> 
>>>> 
>>>> Combine OS and Hardware to one list. Show only OS in the list, which are
>>>> actually supported. For all other problems a category "other" is sufficient.
>>>> 
>>>> Kind regards
>>>> Regina
>> 


Mime
View raw message