Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dave2wave@comcast.net
 designates 76.96.27.243 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [PROPOSAL] Bugzilla Cleanup
From: Dave Fisher <dave2wave@comcast.net>
In-Reply-To: 
 <CAP-ksojaKhg86EG_-SopP6Kd9HpjM60MENty1uOrU1Bjx3CdZA@mail.gmail.com>
Date: Thu, 26 Jan 2012 12:23:46 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <65E88625-F72F-4B90-AA11-D9B52DE04438@comcast.net>
References: 
 <CAP-ksoixkOrb2ZDV5_f3aXu1mZ_FZF89eSkq8pG4pjtB_fgyPQ@mail.gmail.com>
 <4F219A60.5090806@t-online.de>
 <CAP-ksohVPEf37L_cgkBkpPv9hP-O+4jc1aqNWGW7LwkZa-TB2A@mail.gmail.com>
 <B5FA9EEC-1D38-4876-92E4-EBCBBF302B00@comcast.net>
 <CAP-ksojaKhg86EG_-SopP6Kd9HpjM60MENty1uOrU1Bjx3CdZA@mail.gmail.com>
To: ooo-dev@incubator.apache.org


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:
>>=20
>> On Jan 26, 2012, at 11:15 AM, Rob Weir wrote:
>>=20
>>> On Thu, Jan 26, 2012 at 1:24 PM, Regina Henschel
>>> <rb.henschel@t-online.de> wrote:
>>>> Hi Rob,
>>>>=20
>>>> Rob Weir schrieb:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>>=20
>>>> +1
>>>>=20
>>>>=20
>>>>>=20
>>>>> 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.
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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:
>>>=20
>>> Admins
>>> Foo
>>> Default Registered
>>> Unregistered
>>>=20
>>> I'm flexible in what we call "Foo".
>>=20
>> 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.
>>=20
>> I'm actually for three levels and permissive rights for everyone who =
is registered.
>>=20
>> Admins (anyone on the PPMC, Infra, IPMC and Members who wants it)
>> Registered (anyone with a BZ account)
>> Unregistered
>>=20
>> 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.
>>=20
>=20
> 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.

>=20
> 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


>=20
>=20
>> Regards,
>> Dave
>>=20
>>=20
>>=20
>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>> 3) Delete obsolete "products" like bizdev and council.
>>>>=20
>>>>=20
>>>> 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".
>>>>=20
>>>>=20
>>>>>=20
>>>>> 4) Delete the permission groups associated with the removed =
products.
>>>>=20
>>>>=20
>>>> +1
>>>>=20
>>>>=20
>>>>>=20
>>>>> 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"?
>>>>=20
>>>>=20
>>>> 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".
>>>>=20
>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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.
>>>=20
>>>>=20
>>>> 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=3D88964
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> I saw that we had both severity and priority. I could not figure out
>>> how they related to each other.
>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Kind regards
>>>> Regina
>>=20