incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [PROPOSAL] Bugzilla Cleanup
Date Mon, 20 Feb 2012 17:19:40 GMT
top posting...please ignore my last comments on this. I  now have a
*changed* BZ userid (after verification) that is the same as my Apache
email. Sorrrryyyy...

On Mon, Feb 20, 2012 at 9:16 AM, Kay Schenk <kay.schenk@gmail.com> wrote:

>
>
> On Sun, Feb 19, 2012 at 6:52 PM, Rob Weir <robweir@apache.org> wrote:
>
>> On Thu, Jan 26, 2012 at 11:34 AM, Rob Weir <robweir@apache.org> wrote:
>> > 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.
>> >
>>
>> Finally done with this.  It was weeks of work.  Some of this was
>> delayed due to bugs in BZ 4.0.0.  But with the recent upgrade to BZ
>> 4.0.4 I was able to complete the remainder of this tonight.  It was a
>> lot of manual clean up and some batch work.  I tried to do the batch
>> work on weekends and late at night.  Hopefully the notifications were
>> less disruptive at those times.
>>
>> If there are additional changes we need, or if anyone notices a
>> problem, please enter a BZ issue:
>>
>>
>> https://issues.apache.org/ooo/enter_bug.cgi?product=www&component=AOO+Bugzilla
>>
>> > 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.
>> >
>>
>> Done.
>>
>> > 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 did not change permissions of any existing users with elevated
>> permissions.  For example, there were 545 legacy users out of many
>> thousands of users who had "editbugs" permissions.  I have not changed
>> these.
>>
>> What I did do is make sure that anyone registered with an apache.org
>> email address would also have editbugs and canconfirm permissions.
>> That gives any committer/any mentor these same permissions.  If we
>> want to give these permissions to non-committers, that can also be
>> done on a case-by-case basis.  That appears to be how how it was done
>> previously in OOo.
>>
>
> OK, some clarification here. My userid is my old OpenOffice.org email.
> However, I did just change my e-mail preferences to my apache.org email.
> I can't really change my userid.
>
> So, does your statement above refer to the *email* address the user has,
> or their user id?
>
>
>
>
>
> I realize Dave and I have different opinions on how the default
>> registered user permissions should be set.  I've kept it unchanged for
>> now.  I'd like those who are actually doing the testing and trying to
>> develop a QA process in this project determine how best to handle
>> this.  Any change would impact them most, and I think that their
>> preferences on this should count far more than what Dave or I think.
>>
>>
>> > 3) Delete obsolete "products" like bizdev and council.
>> >
>>
>> Since issues were assigned to those products, I did not delete them.
>> But I did consolidate them under a new product called "obsolete".
>>
>> > 4) Delete the permission groups associated with the removed products.
>> >
>>
>> Done.
>>
>> > 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"?
>> >
>>
>> This is fixed now for the major products/components, with the "default
>> assignee" now set to ooo-issues@incubator.apache.org. This will be for
>> new issues.  It did not change the currently assigned assignee for
>> existing issues.
>>
>> > 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.
>> >
>>
>> Done.
>>
>> > 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.
>> >
>> >
>> >
>> > 72 hours, etc.
>> >
>> > Regards,
>> >
>> > -Rob
>>
>
>
>
> --
>
> ----------------------------------------------------------------------------------------
> MzK
>
> "Follow your bliss."
>          -- attributed to Joseph Campbell
>
>
>
>


-- 
----------------------------------------------------------------------------------------
MzK

"Follow your bliss."
         -- attributed to Joseph Campbell

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message