You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2012/01/26 17:34:29 UTC
[PROPOSAL] Bugzilla Cleanup
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.
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.
3) Delete obsolete "products" like bizdev and council.
4) Delete the permission groups associated with the removed products.
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"?
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.
72 hours, etc.
Regards,
-Rob
RE: [PROPOSAL] Bugzilla Cleanup
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 on Regina's comments in general.
I think that the default owner name should be "unassigned". That works fine in other issue-management systems.
The question on what requires committer karma is one that will require more consideration.
- Dennis
-----Original Message-----
From: Regina Henschel [mailto:rb.henschel@t-online.de]
Sent: Thursday, January 26, 2012 10:25
To: ooo-dev@incubator.apache.org
Subject: Re: [PROPOSAL] Bugzilla Cleanup
Hi Rob,
Rob Weir schrieb:
[ ... ]
> 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".
[ ... ]
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Dave Fisher <da...@comcast.net>.
Hi Rob,
Thanks for all of your cleanup work in Bugzilla!
Now after your experience. I'll respond to your points below.
On Jan 26, 2012, at 12:42 PM, Rob Weir wrote:
> On Thu, Jan 26, 2012 at 3:23 PM, Dave Fisher <da...@comcast.net> wrote:
>>
>> On Jan 26, 2012, at 11:54 AM, Rob Weir wrote:
>>
>>> On Thu, Jan 26, 2012 at 2:41 PM, Dave Fisher <da...@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...@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.
If you examine recent ooo-issues emails you should see an example of people who are in this category. For correct name for the group is "former volunteers". I mean this is in the sense that there are people who still have "commiter" rights leftover from OOo who are NOT AOO committers.
I think this is OK because we should trust everyone until they give us reasons to distrust them.
>>
>> 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 do not trust someone who merely signed up on the BZ instance anytime
> in the past 5 years.
Communities grow when they trust, but verify. Not trusting users for "merely" being interested does not help a community grow.
>
> Remember, when it comes time for PMC members to vote on a release,
> none of us will have verified every bug and zero of us will have
> tested every feature of the product. We'll need to rely on test
> results and what is in BZ to make an informed decision on whether a
> release is ready or not.
We need to trust those on the PPMC and Committers they have signed the ICLA. Trust is required. But checking is good.
Ready is three things (at least)
(1) Is the IP correct? Especially LICENSE and NOTICE.
And it is really, really lucky that there are tools like Apache RAT, or big projects could never release. Everyone voting needs to run RAT and check the output.
(2) Are the release artifacts correctly built and signed?
Everyone who votes must verify signatures to all release artifacts. This is something the PPMC should discuss when it is time to decide what exactly is in the release.
(3) Is the release an improvement for users to a previous version?
Your subjective criteria.
>
> When you edit a wiki or something like that, you are making a
> contribution to the project. It can be good, it can be bad, but it is
> a tangible contribution. If someone puts spam on the wiki, any of us
> can see that and reverse it. If someone puts poorly worked content on
> the wiki, with bad spelling or broken links, we can automatically
> detect that. At the very lease, the next project member that visits
> the page can see the problem.
It is the very least. Oversight requires that people visit the page and change it. For this projects Wikis.
- MediaWiki - Commit without Review. There is no email of changes to a project ML.
- CWiki (Users) - CTR. There is an email that a page was changed to ooo-commits.
> Bugzilla issues are absolute not like this,. It is impossible to
> tell, by inspection, whether an issue was closed legitimately or
> illegitimately. That makes all the difference. Since we have no
> ability to retest 100% of closed issues, we need to rely on trust.
- BZ - is CTR (in BZ). There *IS* an email to ooo-issues when an issue is changed. This is better review than CWiki.
Note - a Committer has to do something with a bug.
> Since we do not currently and will not ever have the resources to have
> every PMC member test every bug, or even to expect that all resolved
> bugs will be tested even twice before closing, we need to rely on our
> testers to get this right. If they mark a bug as fixed and verified,
> based on their testing, then we need to have very high confidence in
> their capabilities. If they get it wrong, then in all likelihood the
> bug makes it into the released product.
Just because someone changes the state, doesn't mean committers cannot review closed bugs to see if they were properly closed!
SVN - CTR. There is an email to ooo-commits.
> I am absolutely unwilling to allow the ability to close, verify or
> similar to a random anonymous user who registers with the system.
> That would be suicidal.
We have to trust each other.
> We can certainly allow someone to enter a comment that says they
> tested and the bug appears to be fixed. But we need to allow our
> testers to perform their role, and that role is one of quality
> control, again, note the word "control".
Who do you think our "testers" are? And how are we going to find more? The only diverse way is to allow unfettered access to BZ. for registered users.
> The status of a bug is
> critical information in the project, some of the most important info
> we track. If random people have the ability to remove bugs from
> their view, by closing them out, then we have no control over the
> quality of the project, and as a PMC member, I don't see how I could
> ever approve a release.
Follow ooo-issues and do verification. Anyone including non-commiters could do it.
>
> Maybe another angle would help see this more clearly. We allow code
> contributions from anyone, in the form of patches. But we do not
> apply those patches automatically, without review. Why? Because
> there is a difference between community inclusiveness and the desire
> to receive contributions, and the need for quality and the trust that
> comes with being a committer. These are two different things.
>
> Ditto for BZ. We can be open to contributions in the form of new
> issues and comments on existing issues, but also reserve for
> trustworthy individuals, such as committers, the actions that imply in
> the workflow that the bug has been verified.
>
> Make sense?
Yes, but I trust more and therefore draw the line further out for BZ than you do. I would put that trust line out as from the center as we already accept for both the Wikis. I also know we have the better oversight on the ML compared to CWiki and MediaWiki.
It will be less work for BZ Admins to just give every registered user equal permissive rights.
The ooo-issues ML allows the community to be on the lookout for unusual activity and the volunteer admin can be called to act when spammers or malefactors arrive.
Our Mentors may comment on how frequently users abuse permissive rights.
If your concerns are more than hypothetical you know the forum for that.
Regards,
Dave
>
> -Rob
>
>
>> 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
>>>>
>>
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 26, 2012 at 3:23 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Jan 26, 2012, at 11:54 AM, Rob Weir wrote:
>
>> On Thu, Jan 26, 2012 at 2:41 PM, Dave Fisher <da...@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...@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 do not trust someone who merely signed up on the BZ instance anytime
in the past 5 years.
Remember, when it comes time for PMC members to vote on a release,
none of us will have verified every bug and zero of us will have
tested every feature of the product. We'll need to rely on test
results and what is in BZ to make an informed decision on whether a
release is ready or not.
When you edit a wiki or something like that, you are making a
contribution to the project. It can be good, it can be bad, but it is
a tangible contribution. If someone puts spam on the wiki, any of us
can see that and reverse it. If someone puts poorly worked content on
the wiki, with bad spelling or broken links, we can automatically
detect that. At the very lease, the next project member that visits
the page can see the problem.
Bugzilla issues are absolute not like this,. It is impossible to
tell, by inspection, whether an issue was closed legitimately or
illegitimately. That makes all the difference. Since we have no
ability to retest 100% of closed issues, we need to rely on trust.
Since we do not currently and will not ever have the resources to have
every PMC member test every bug, or even to expect that all resolved
bugs will be tested even twice before closing, we need to rely on our
testers to get this right. If they mark a bug as fixed and verified,
based on their testing, then we need to have very high confidence in
their capabilities. If they get it wrong, then in all likelihood the
bug makes it into the released product.
I am absolutely unwilling to allow the ability to close, verify or
similar to a random anonymous user who registers with the system.
That would be suicidal.
We can certainly allow someone to enter a comment that says they
tested and the bug appears to be fixed. But we need to allow our
testers to perform their role, and that role is one of quality
control, again, note the word "control". The status of a bug is
critical information in the project, some of the most important info
we track. If random people have the ability to remove bugs from
their view, by closing them out, then we have no control over the
quality of the project, and as a PMC member, I don't see how I could
ever approve a release.
Maybe another angle would help see this more clearly. We allow code
contributions from anyone, in the form of patches. But we do not
apply those patches automatically, without review. Why? Because
there is a difference between community inclusiveness and the desire
to receive contributions, and the need for quality and the trust that
comes with being a committer. These are two different things.
Ditto for BZ. We can be open to contributions in the form of new
issues and comments on existing issues, but also reserve for
trustworthy individuals, such as committers, the actions that imply in
the workflow that the bug has been verified.
Make sense?
-Rob
> 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
>>>
>
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Dave Fisher <da...@comcast.net>.
On Jan 26, 2012, at 11:54 AM, Rob Weir wrote:
> On Thu, Jan 26, 2012 at 2:41 PM, Dave Fisher <da...@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...@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
>>
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 26, 2012 at 2:41 PM, Dave Fisher <da...@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...@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?
But I am happy to have a "trusted volunteer" group that we can add
trusted volunteers to, on request, to give them additional
permissions.
> 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
>
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Dave Fisher <da...@comcast.net>.
On Jan 26, 2012, at 11:15 AM, Rob Weir wrote:
> On Thu, Jan 26, 2012 at 1:24 PM, Regina Henschel
> <rb...@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.
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
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 26, 2012 at 1:24 PM, Regina Henschel
<rb...@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".
>
>>
>> 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
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Regina;
--- Gio 26/1/12, Regina Henschel <rb...@t-online.de> ha scritto:
>
> 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.
>
The term is indeed somewhat misunderstood. Committer in
Apache means someone involved with the project. Write
access to SVN is one thing that comes with becoming a
committer but it's not something committers are expected
to do.
Formal committers get access not only to SVN but also to
edit wikis and other apache infrastructure that normal
users cant. We do have plenty of committers that are not
doing changes to the code but that are working on the
webpages or the wikis or simply contributing by email.
While privileges for the bugzilla instance were transferred
along with the database, this was a one time thing that
will likely have to be adjusted. I would expect that from
now on the only way to get such privileges is after
becoming a formal committers.
Becoming a committer is no huge mystery as one may think.
cheers,
Pedro.
> >
> > 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.
>
>
> 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.
>
>
> 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
>
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Regina Henschel <rb...@t-online.de>.
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.
>
> 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.
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.
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
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Kay Schenk <ka...@gmail.com>.
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 <ka...@gmail.com> wrote:
>
>
> On Sun, Feb 19, 2012 at 6:52 PM, Rob Weir <ro...@apache.org> wrote:
>
>> On Thu, Jan 26, 2012 at 11:34 AM, Rob Weir <ro...@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
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Feb 19, 2012 at 6:52 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jan 26, 2012 at 11:34 AM, Rob Weir <ro...@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
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Pedro Giffuni <pf...@apache.org>.
Hello;
--- Dom 19/2/12, Rob Weir <ro...@apache.org> ha scritto:
>
> 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
It is more of a wishlist item than anything else but
there was an attempt to rescue the traditional OOo
styling that was left unfinished [1].
A hacked OpenOffice.org skin can be activated in
bugzilla preferences but at the time that is not
recommendable. It would be great if someone with
the know how and a taste for this things takes
over.
thanks,
Pedro.
https://issues.apache.org/jira/browse/INFRA-3970 [1]
Re: [PROPOSAL] Bugzilla Cleanup
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 26, 2012 at 11:34 AM, Rob Weir <ro...@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.
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