incubator-ooo-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 Wed, 01 Feb 2012 22:35:32 GMT
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 <dave2wave@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 <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.

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


Mime
View raw message