Discussion:
Minutes of the last Bugzilla meeting
(too old to reply)
Frédéric Buclin
2007-01-10 14:24:20 UTC
Permalink
We had a Bugzilla meeting yesterday. You can read the minutes there:

http://wiki.mozilla.org/Bugzilla:Meetings:2007-01-09

or below:

* Max Kanat-Alexander (mkanat) and Frédéric Buclin (LpSolit) are now
allowed to grant approval on bugs. So the team of approvers for the
Bugzilla product is now justdave, myk, mkanat and LpSolit.

* mkanat will check whether the last webservice bug is really a blocker
for 3.0 or not. That's the very last bug remaining on our roadmap for 3.0.

* No major problems found following the upgrade of bugzilla.mozilla.org
(aka b.m.o). Most serious bugs were fixed within 48-72 hours. b.m.o nows
runs smoothly with mod_perl enabled. Thanks to justdave and reed for the
hard work before and during the upgrade.

* We decided to drop the 2.23.4 release. We got enough feedback since
the upgrade of the b.m.o installation 2 weeks ago to feel confident with
our current code. So our next release will be 3.0 RC1.

* We don't agree whether the Bugzilla project should have its own
Bugzilla installation (e.g. bugzilla.bugzilla.org) or not. Some of us
see dogfood as a good way to test our own code. One drawback is that
moving bugs between Mozilla products (e.g. the mozilla.org or b.m.o
products) and the Bugzilla product would be a pain. This would also
break saved searches which are not able to query 2 separate
installations in one shot. Also, users would probably hate to have 2
separate accounts to report bugs.

* The QA team will have to redo all QA tests again as we finally didn't
release 2.22.2 and 2.23.4 on mid-December, despite QA tests were all
done and passed successfully. There has been too many checkins since the
b.m.o upgrade so that new tests are required again. As we will move
directly to 3.0 RC1, the QA team will wait for all remaining blockers to
be fixed before running them again, though.

* 7 blockers left to fix before releasing 3.0 RC1. 3 of them only affect
the bugzilla.org website (updating the documentation, documenting new
features, building required RPM packages for distros which don't have
them).

* 3.0 RC1 won't be ready before the second half of February, probably.

* We will have some help from the Mozilla Corporation for the Press
Release when Bugzilla 3.0 will come out.

* "Make Bugzilla easily pluggable" summaries where Bugzilla should go
for future major releases. In other words, it should be easier for 3rd
parties to write plugins. This will let us focus on the bug tracking
tool aspect of the product, but allowing extensions to be added.

* Our next meeting will take place on January 23, same time.


LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
David Miller
2007-01-10 20:41:08 UTC
Permalink
Frédéric Buclin wrote on 1/10/07 9:24 AM:

> * We will have some help from the Mozilla Corporation for the Press
> Release when Bugzilla 3.0 will come out.

What I said in the meeting was:

12:21:47 <@justdave> oh, some other news, MoCo is probably going to help
us with some minimal PR surrounding the 3.0 release

That says "probably," not "will." PR in this context also means
public/press relations as a general concept, not necessarily just a
press release (though that may end up being all it is).

I've corrected the minutes entry on the wiki to read:

* We will probably have some kind of help from the Mozilla Corporation
with public/press relations when Bugzilla 3.0 comes out.


--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-10 20:50:25 UTC
Permalink
> I've corrected the minutes entry on the wiki to read:
>
> * We will probably have some kind of help from the Mozilla Corporation
> with public/press relations when Bugzilla 3.0 comes out.


OK, sorry for the mistake. I didn't look close enough at the exact
wording you used.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Nicolas Doye
2007-01-10 20:58:01 UTC
Permalink
Did the Oracle people say anything at the meeting?

nic

On 10/01/07, Frédéric Buclin <***@gmail.com> wrote:
>
> > I've corrected the minutes entry on the wiki to read:
> >
> > * We will probably have some kind of help from the Mozilla Corporation
> > with public/press relations when Bugzilla 3.0 comes out.
>
>
> OK, sorry for the mistake. I didn't look close enough at the exact
> wording you used.
>
> LpSolit
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=***@worldofnic.org>
>



--
http://worldofnic.org
Frédéric Buclin
2007-01-10 21:02:00 UTC
Permalink
> Did the Oracle people say anything at the meeting?


Nobody from Oracle was present.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-10 23:19:18 UTC
Permalink
David Miller wrote:
> 12:21:47 <@justdave> oh, some other news, MoCo is probably going to help
> us with some minimal PR surrounding the 3.0 release
>
> That says "probably," not "will." PR in this context also means
> public/press relations as a general concept, not necessarily just a
> press release (though that may end up being all it is).

As Bugzilla is not a MoCo product, MoFo may also be able to help here;
we've done so for Camino and Seamonkey in the past.

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-10 23:18:24 UTC
Permalink
Frédéric Buclin wrote:
> * We don't agree whether the Bugzilla project should have its own
> Bugzilla installation (e.g. bugzilla.bugzilla.org) or not. Some of us
> see dogfood as a good way to test our own code. One drawback is that
> moving bugs between Mozilla products (e.g. the mozilla.org or b.m.o
> products) and the Bugzilla product would be a pain.

...then we fix moving.

> This would also
> break saved searches which are not able to query 2 separate
> installations in one shot.

...then we fix saved searches.

> Also, users would probably hate to have 2
> separate accounts to report bugs.

...then we fix it so we can use a separate database for logins, or use LDAP.

This dogfood stuff works really well ;-)

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Jake
2007-01-21 23:58:20 UTC
Permalink
Gervase Markham wrote:
> Frédéric Buclin wrote:
>> Also, users would probably hate to have 2 separate accounts to report
>> bugs.
>
> ...then we fix it so we can use a separate database for logins, or use
> LDAP.


Or OpenID :)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Luis Villa
2007-01-24 16:41:25 UTC
Permalink
On 1/21/07, Jake <jake-***@public.gmane.org> wrote:
> Gervase Markham wrote:
> > Frédéric Buclin wrote:
> >> Also, users would probably hate to have 2 separate accounts to report
> >> bugs.
> >
> > ...then we fix it so we can use a separate database for logins, or use
> > LDAP.
>
>
> Or OpenID :)

Having finally created an openid account, I've seen the light and
heartily second this request. Should make all of our lives much easier
when it is more widely deployed.

Luis
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gunnar Wagenknecht
2007-01-11 13:22:05 UTC
Permalink
Frédéric Buclin wrote:
> * 3.0 RC1 won't be ready before the second half of February, probably.

Will the skin redesign exposed at b.m.o be part of Bugzilla 3.0? I've
checked out the latest code from head and the show bug page looks
different from what is exposed as b.m.o.

CU, Gunnar

--
Gunnar Wagenknecht
gunnar-DDAdSCQIZD/***@public.gmane.org
http://wagenknecht.org/

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
David Miller
2007-01-15 04:46:06 UTC
Permalink
Gunnar Wagenknecht wrote on 1/11/07 8:22 AM:
> Frédéric Buclin wrote:
>> * 3.0 RC1 won't be ready before the second half of February, probably.
>
> Will the skin redesign exposed at b.m.o be part of Bugzilla 3.0? I've
> checked out the latest code from head and the show bug page looks
> different from what is exposed as b.m.o.

That's a matter of some debate. :) A lot of what wound up going in
there is pretty Firefox-centric. There are some of the concepts that
got put in there getting put into CVS though, but not all. Feel free to
discuss if there's parts of it you like that haven't made it into CVS
yet. :) (probably ought to start a new thread though so people notice
it and don't think it's just meeting followup)

--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-15 14:54:32 UTC
Permalink
Gunnar Wagenknecht wrote:
> Frédéric Buclin wrote:
>
>> * 3.0 RC1 won't be ready before the second half of February, probably.
>>
>
> Will the skin redesign exposed at b.m.o be part of Bugzilla 3.0? I've
> checked out the latest code from head and the show bug page looks
> different from what is exposed as b.m.o.
>
> CU, Gunnar
>
>
I would rather it didn't get in (at least not as the default). While it
is great for reporters and people looking for bugs, I think it is worse
for the people actually fixing the bugs. In a bug you now scroll all the
way to the bottom to read the last couple comments, then scroll back to
the top to change some aspect of the bug, and then back to the bottom to
add a comment or reassign it.

(note, I am talking about show_bug, nothing else)
Frédéric Buclin
2007-01-15 16:12:53 UTC
Permalink
> is great for reporters and people looking for bugs, I think it is worse
> for the people actually fixing the bugs. In a bug you now scroll all the
> way to the bottom to read the last couple comments, then scroll back to
> the top to change some aspect of the bug, and then back to the bottom to
> add a comment or reassign it.

That's one of the reasons some of us dislike the UI on b.m.o. For
triagers and QA people who don't need to comment, but only to change
some fields, it's a pain to scroll up and down all the time.

Another question of debate is the place where the keywords, status
whiteboard and URL fields are. Probably they shouldn't be so high in the
page, as most(?) of us probably don't use or need them. The assignee and
target milestone seem more important. But this is really a question of
taste, and as long as there is no consensus, we will probably keep the
current UI which is by far not perfect, but much better than the one we
currently have in 2.22.

One part of the UI which will be ported upstream for 3.0 is the
attachment table (the patch is currently under review) as there is a
good consensus about it.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-15 16:23:44 UTC
Permalink
Frédéric Buclin wrote:
> That's one of the reasons some of us dislike the UI on b.m.o. For
> triagers and QA people who don't need to comment, but only to change
> some fields, it's a pain to scroll up and down all the time.

Yes. It seems to me that the important parts of the page to most people
are the fields, the comment box and the most recent comment. With the
previous layout, you could get them all together by reversing the
direction of the comments. (I never tried that, but I'd be willing to
give it a go.) But with the new layout, they are miles apart whatever
direction you have the comments in, because the comment box is always at
the bottom.

We should at least have a Commit button up the top as well (and space
the other Commit button further from the knob, but that's another point).

> Another question of debate is the place where the keywords, status
> whiteboard and URL fields are. Probably they shouldn't be so high in the
> page, as most(?) of us probably don't use or need them. The assignee and
> target milestone seem more important.

I certainly have to keep hunting around to find the assignee.

> But this is really a question of
> taste, and as long as there is no consensus, we will probably keep the
> current UI which is by far not perfect, but much better than the one we
> currently have in 2.22.

Well, there may be no consensus, but there is "what people are used to";
and in absence of consensus, something which doesn't force everyone to
retrain should be preferred.

> One part of the UI which will be ported upstream for 3.0 is the
> attachment table (the patch is currently under review) as there is a
> good consensus about it.

I agree; I like it, apart from I think some of the fonts are a bit small.

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-15 16:48:55 UTC
Permalink
Frédéric Buclin wrote:
>> is great for reporters and people looking for bugs, I think it is
>> worse for the people actually fixing the bugs. In a bug you now
>> scroll all the way to the bottom to read the last couple comments,
>> then scroll back to the top to change some aspect of the bug, and
>> then back to the bottom to add a comment or reassign it.
>
> That's one of the reasons some of us dislike the UI on b.m.o. For
> triagers and QA people who don't need to comment, but only to change
> some fields, it's a pain to scroll up and down all the time.
>
> Another question of debate is the place where the keywords, status
> whiteboard and URL fields are. Probably they shouldn't be so high in
> the page, as most(?) of us probably don't use or need them. The
> assignee and target milestone seem more important. But this is really
> a question of taste, and as long as there is no consensus, we will
> probably keep the current UI which is by far not perfect, but much
> better than the one we currently have in 2.22.
In our bugzilla (stellarfinancial) most of the users use keywords,
status whiteboard, and assignee. The url field is not important, neither
is target milestone, hardware or OS. We will be implementing a custom
type field (https://bugzilla.mozilla.org/show_bug.cgi?id=9412) or
waiting for it to be implemented in cvs and this field will be important
to us.

I have experimented with creating two separate bug pages (edit-bug and
view-bug) to try to resolve this issue, but I don't feel like I have
gotten positive feedback on it
(https://bugzilla.mozilla.org/show_bug.cgi?id=345674, ignore colors; I
am colorblind, they wont stay, they are just there to help identify
sections on the page). The eventual idea would be to have a user pref
about which to initially display on a bug and then allow a user to
switch between the two.
>
> One part of the UI which will be ported upstream for 3.0 is the
> attachment table (the patch is currently under review) as there is a
> good consensus about it.
What bug is this? Have we looked at considering the darwin bugzilla's
extra features on their attachment tables (highlight row when mouseover
for example)?
>
> LpSolit
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout-***@public.gmane.org>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Kevin Benton
2007-01-15 17:08:38 UTC
Permalink
Bill Barry wrote:
> Frédéric Buclin wrote:
>>> is great for reporters and people looking for bugs, I think it is
>>> worse for the people actually fixing the bugs. In a bug you now
>>> scroll all the way to the bottom to read the last couple comments,
>>> then scroll back to the top to change some aspect of the bug, and
>>> then back to the bottom to add a comment or reassign it.
>>
>> That's one of the reasons some of us dislike the UI on b.m.o. For
>> triagers and QA people who don't need to comment, but only to change
>> some fields, it's a pain to scroll up and down all the time.
>>
>> Another question of debate is the place where the keywords, status
>> whiteboard and URL fields are. Probably they shouldn't be so high in
>> the page, as most(?) of us probably don't use or need them. The
>> assignee and target milestone seem more important. But this is really
>> a question of taste, and as long as there is no consensus, we will
>> probably keep the current UI which is by far not perfect, but much
>> better than the one we currently have in 2.22.
> In our bugzilla (stellarfinancial) most of the users use keywords,
> status whiteboard, and assignee. The url field is not important,
> neither is target milestone, hardware or OS. We will be implementing a
> custom type field (https://bugzilla.mozilla.org/show_bug.cgi?id=9412)
> or waiting for it to be implemented in cvs and this field will be
> important to us.
>
> I have experimented with creating two separate bug pages (edit-bug and
> view-bug) to try to resolve this issue, but I don't feel like I have
> gotten positive feedback on it
> (https://bugzilla.mozilla.org/show_bug.cgi?id=345674, ignore colors; I
> am colorblind, they wont stay, they are just there to help identify
> sections on the page). The eventual idea would be to have a user pref
> about which to initially display on a bug and then allow a user to
> switch between the two.
>>
>> One part of the UI which will be ported upstream for 3.0 is the
>> attachment table (the patch is currently under review) as there is a
>> good consensus about it.
> What bug is this? Have we looked at considering the darwin bugzilla's
> extra features on their attachment tables (highlight row when
> mouseover for example)?
>>
>> LpSolit
>>
>
If I remember correctly, there was a very nice AJAX solution that
allowed users to move parts of the bug display around changing the basic
layout to suit their needs. I don't know if it makes sense to consider
something similar here, though I don't think it's fair to ask that it
would land in 3.0. My suggestion is that we allow certain blocks to 1)
be collapsible, and 2) be shiftable - meaning that the sequence can be
changed. For example, some want the comment entry block at the bottom.
Some want it below the fields listing. Some don't want to see certain
parts of the bug display (flags for example). By allowing blocks to be
collapsible and shiftable, users can move what they need to see first to
the top of a bug. I agree with the other commenter that mentioned that
they thought there ought to be a commit button near the top of the bug
(I think it was LpSolit).

In any case, I think we ought to also implement Javascript that checks
to see if any field on the form has been changed before allowing users
to hit their back button or click on one of the page's links. That way,
users can't leave a page without being given the opportunity to submit
the changes first. I don't know if this has already been done in 3.0
yet, though I think it's becoming more and more critical as our user
interface becomes more user-friendly. Many applications now auto-submit
so users don't have to click on a submit button, making it more likely
that users will forget to click a submit button so their changes aren't
lost.

Kevin

--
Kevin Benton
2007-01-15 17:31:03 UTC
Permalink
Gervase Markham wrote:
> Kevin Benton wrote:
>> My suggestion is that we allow certain blocks to 1) be collapsible,
>> and 2) be shiftable - meaning that the sequence can be changed. For
>> example, some want the comment entry block at the bottom. Some want
>> it below the fields listing. Some don't want to see certain parts of
>> the bug display (flags for example). By allowing blocks to be
>> collapsible and shiftable, users can move what they need to see first
>> to the top of a bug.
>
> My concern about this would be that it would severely restrain our
> ability to make later changes to the underlying template. If a
> thousand people have made and stored particular arrangements, we would
> have an obligation to keep them all working and looking roughly the
> same. There's no way we could do that testing even if we wanted to.
HI Gerv,

It seems to me that with the advent of custom fields, that this would be
a reasonable requirement - to be able to shift where certain blocks of
fields appear. I'm not suggesting that we allow all fields to appear in
a random order. That's something individual site admins can accomplish
through their own custom templates. OTOH, I do think it's fair to
suggest that a block of fields should be semi-movable meaning that it
would have a certain list of areas where it could appear.

Maybe I'm over-reaching with this request from a testing standpoint, but
from a usability perspective, I believe it would add a lot to the
interface by making blocks of fields movable and/or collapsible in a
semi-limited fashion.

Kevin

--
Gervase Markham
2007-01-15 17:20:13 UTC
Permalink
Kevin Benton wrote:
> My suggestion is that we allow certain blocks to 1)
> be collapsible, and 2) be shiftable - meaning that the sequence can be
> changed. For example, some want the comment entry block at the bottom.
> Some want it below the fields listing. Some don't want to see certain
> parts of the bug display (flags for example). By allowing blocks to be
> collapsible and shiftable, users can move what they need to see first to
> the top of a bug.

My concern about this would be that it would severely restrain our
ability to make later changes to the underlying template. If a thousand
people have made and stored particular arrangements, we would have an
obligation to keep them all working and looking roughly the same.
There's no way we could do that testing even if we wanted to.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-15 17:44:49 UTC
Permalink
Kevin Benton wrote:
> If I remember correctly, there was a very nice AJAX solution that
> allowed users to move parts of the bug display around changing the
> basic layout to suit their needs.
As far as I know, this was just for the home page screen and it only
involved saved search buglists.
> I don't know if it makes sense to consider something similar here,
> though I don't think it's fair to ask that it would land in 3.0. My
> suggestion is that we allow certain blocks to 1) be collapsible,
Good. Or simply that several less used blocks occupy the same space in
client side tabs.
> and 2) be shiftable - meaning that the sequence can be changed. For
> example, some want the comment entry block at the bottom. Some want
> it below the fields listing. Some don't want to see certain parts of
> the bug display (flags for example). By allowing blocks to be
> collapsible and shiftable, users can move what they need to see first
> to the top of a bug.
That could quickly become a nightmare for changes we may want to make to
the templates sometime in the future. We would need to tread very
carefully into these waters.
> I agree with the other commenter that mentioned that they thought
> there ought to be a commit button near the top of the bug (I think it
> was LpSolit).
Yes, definitely needed.
A small (hidden by default) comment box would be welcome (by me) as
well. Display it when a user clicks on a # symbol (or something like
that) in the gray bug header bar. On that matter, it could be shown when
you click the edit link in the bar. Then again, the bmo is a place to
fix bugs, not a forum. Having the comment box so far down the page does
seem to make it a little less inviting.
>
> In any case, I think we ought to also implement Javascript that checks
> to see if any field on the form has been changed before allowing users
> to hit their back button or click on one of the page's links. That
> way, users can't leave a page without being given the opportunity to
> submit the changes first. I don't know if this has already been done
> in 3.0 yet, though I think it's becoming more and more critical as our
> user interface becomes more user-friendly. Many applications now
> auto-submit so users don't have to click on a submit button, making it
> more likely that users will forget to click a submit button so their
> changes aren't lost.
Providing visual notification of changes would be good too. Is there
some sort of :changed pseudo class for form elements? That would be an
ideal starting point for this, something like:
:changed {
font-weight: bold;
background-color: #e0e0ff;
}

>
> Kevin
>
> --
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout-***@public.gmane.org>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Wayne Mery
2007-01-15 22:40:28 UTC
Permalink
Approximately half of you mentioned placement of the comment box.
Perhaps this issue can be more easily addressed (with concensus) than
other issues?

However, I submit even 2.22's top placement (which for those with
editbug seems to be the concensus preference) is not ideal. I must
scroll to see the first or most recent comments or get past attachments
section (which I rarely need to see) and then scroll back up to change
any fields. I'd really rather see everything at once, or at least not
have to scroll much more than one page.

Has anyone tested a side-by-side arrangement? That is, have comments
start at the top of page in a scrollable column of their own next to the
labels?

I'd appreciate your comments on an example I've mocked up
http://i13.tinypic.com/2wehvg7.png Can it be mocked up on landfill?


For reporters and the like who don't have edit privs - 2.23's bottom
placement might encourage users to read the latest comments before
commenting themselves. OTOH 2.22's top placement, below attachments and
above comment 0, encourages nothing IMO - reading of the reporter's STR
or the last comments. So perhaps 2.23's setup is better.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-15 22:47:49 UTC
Permalink
> Approximately half of you mentioned placement of the comment box.
> Perhaps this issue can be more easily addressed (with concensus) than
> other issues?

This issue is specific to b.m.o. Has nothing to do with Bugzilla 3.0.


> Has anyone tested a side-by-side arrangement? That is, have comments
> start at the top of page in a scrollable column of their own next to the
> labels?
>
> I'd appreciate your comments on an example I've mocked up


I have to scroll horizontally to see comments. Meaning that you should
narrow the left column, meaning that you would have to scroll even more
to see all fields. Not sure that's a good idea.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Wayne Mery
2007-01-15 23:05:21 UTC
Permalink
On 1/15/2007 5:47 PM, Frédéric Buclin wrote:

> I have to scroll horizontally to see comments. Meaning that you should
> narrow the left column, meaning that you would have to scroll even more
> to see all fields. Not sure that's a good idea.

what screen size are you using?

As you state it of course it's not a good idea ... but then it does
depends on one's screen size, font size and how one arranges the left
two columns (but not necessarily all three). For myself I can see it
working very nicely, should be technically feasible to implement, and
better (for me) than all the currently available choices.


Post 3.0, are there any UI objectives? And what are constraints
will/should be placed on ideas that are submitted?

Is the "personalities" project still a factor?
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-15 23:10:57 UTC
Permalink
> what screen size are you using?

17", 1024 x 768 pixels.


> Post 3.0, are there any UI objectives? And what are constraints
> will/should be placed on ideas that are submitted?

Currently no strong post-3.0 objective. We will discuss about this as
soon as 3.0 RC1 is released and the trunk open again for development.
One direction is to make Bugzilla usable on small devices.


> Is the "personalities" project still a factor?

This project is pretty dead AFAIK. gerv is the one who was working on
it. He could tell us more about it.


LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-16 01:00:14 UTC
Permalink
Frédéric Buclin wrote:
>> what screen size are you using?
>
> 17", 1024 x 768 pixels.
>
>
>> Post 3.0, are there any UI objectives? And what are constraints
>> will/should be placed on ideas that are submitted?
>
> Currently no strong post-3.0 objective. We will discuss about this as
> soon as 3.0 RC1 is released and the trunk open again for development.
> One direction is to make Bugzilla usable on small devices.
I have a couple of objectives for post 3.0 that I want to push (in no
particular order):
1. making it very easy to script against and integrate with (email_in
goes almost all the way here, I only want a little more; something to
query from the command line with, and to retrieve the new bug number
when you submit an email through the email_in interface)
2. a contrib patch to allow secure authenticated inbound emails (I'd
love to be able to reply to a bugzilla email and get my comment in on
the bug; even better would be to be able to modify the bug using the
@param syntax). I don't know how this should be done though (I do know
that email_in shouldn't be touched to allow this)

specific to web UI:
3. better use of the header links section (I think your own saved
searches should go there: "Home | New | Search | saved 1 | saved 2 |
saved 3", no "My bugs", no shared searches)
4. put a searchbox and a couple links in the top right corner (the
searchbox from the homepage, and underneath it put "My bugs | prefs |
logout ***@domain"
5. display the version in the footer on every page (pref bottom right in
a float box that takes up no height)
6. make the tabs smaller (I hate that enormous tab in the search page
and user preferences)
7. make it easier to get around the admin sections
(https://bugzilla.mozilla.org/show_bug.cgi?id=325487)
8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412
9. more bug views (currently we have edit, print, and xml; a slimmed
down edit would be nice with things rearranged)

for an example of what I am talking about (items 3,4,5):
https://systems-300.stellarfinancial.com/bugzilla-tip/
png attachment: https://bugzilla.mozilla.org/attachment.cgi?id=230646
bug for items 3 and 4: https://bugzilla.mozilla.org/show_bug.cgi?id=345229

demo of smaller tabs (ignore colors):
https://bugzilla.mozilla.org/attachment.cgi?id=232221 (on a bug about
show_bug UI: https://bugzilla.mozilla.org/show_bug.cgi?id=345674)

A couple things I think would be nice:
linkify the status whiteboard label to a comment # if there is a comment
number in the whiteboard
rows highlight on mouseover in the attachments table and buglists (just
a little bit to make it easy to identify the whole row)
alternating rows in buglist alternate in color in all possible cases
(don't modify the background color because of a priority/severity)
second skin

*note, I haven't voted on any of these, or submitted patches (or bugs)
to some of the items in this mail due to lack of time, and that I didn't
want to derail 3.0 (I feel that mod_perl, custom fields and email_in are
some of the most important features ever to be released in bugzilla, and
they should get out as soon as possible). I will not submit any new
patches on any of these at least until 3.0 branches.
>
>
>> Is the "personalities" project still a factor?
>
> This project is pretty dead AFAIK. gerv is the one who was working on
> it. He could tell us more about it.
>
>
> LpSolit
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout-***@public.gmane.org>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Max Kanat-Alexander
2007-01-16 02:33:11 UTC
Permalink
On Mon, 15 Jan 2007 20:00:14 -0500 Bill Barry <after.fallout-***@public.gmane.org>
wrote:
> 1. making it very easy to script against and integrate with

There is already a tool to do a command line query.

There is already an XML-RPC interface.

> retrieve the new bug number when you submit an email through the
> email_in interface)

That's a good idea. Please file a bug.

> 2. a contrib patch to allow secure authenticated inbound emails

This doesn't have to be contrib. I already have code that does
this, I just have to wait for copyright release on it. We have already
planned to do this.

> 3. better use of the header links section (I think your own saved
> searches should go there:

Some people have 50 saved searches.

> 4. put a searchbox and a couple links in the top right corner

That's not necessary--those links are already there in the
standard header.

> 5. display the version in the footer on every page (pref bottom right
> in a float box that takes up no height)

It's already in the header. Are you looking at bmo instead of
actual upstream?

> 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412

Note that that's trivially implemented by adding a "cf_type"
select field in your own Bugzilla.


-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-16 09:43:06 UTC
Permalink
>> 5. display the version in the footer on every page (pref bottom right
>> in a float box that takes up no height)

No, this won't happen. This information is not important enough to be
displayed everywhere. There are more important stuff to display in the
footer. We already rejected such a request (WONTFIX).

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-16 14:11:52 UTC
Permalink
>> 2. a contrib patch to allow secure authenticated inbound emails
>>
>
> This doesn't have to be contrib. I already have code that does
> this, I just have to wait for copyright release on it. We have already
> planned to do this.
>
How would you do this? Client certs? GPG?
I have a script that will allow inbound email from the inside of our
network (it works very much like fetchmail, in fact I bet it could be
replaced with fetchmail), but it doesn't authenticate in any way. An
authentication mechanism that anyone can use without getting in the way
of normal email sending/recieving (through outlook and exchange) would
be awesome (I could open the script up to the outside) but I haven't
figured out how to do it.
>
>> 3. better use of the header links section (I think your own saved
>> searches should go there:
>>
>
> Some people have 50 saved searches.
>
So have the ability to show your saved searches in the header and/or
footer in user prefs.
>> 5. display the version in the footer on every page (pref bottom right
>> in a float box that takes up no height)
>>
>
> It's already in the header. Are you looking at bmo instead of
> actual upstream?
>
Because I have replaced it in the header with a searchbox, I moved it to
the footer. The header is much more valuable space than the footer and
should be wisely used.
>
>> 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412
>>
>
> Note that that's trivially implemented by adding a "cf_type"
> select field in your own Bugzilla.
>
Which is exactly what I am doing (and what the bug says). The only
reason I haven't done it yet is that you say in the bug that we should
have it in mainline bugzilla for 3.0 (or 3.2). If it gets in to the main
bugzilla would this cause any issues for those of us that have already
implemented a custom field with the same name? Is this a testcase that
has been considered?
>
> -Max
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-16 16:27:07 UTC
Permalink
> have it in mainline bugzilla for 3.0 (or 3.2). If it gets in to the main
> bugzilla would this cause any issues for those of us that have already
> implemented a custom field with the same name? Is this a testcase that
> has been considered?

All custom field names begin with "cf_". None of the fields implemented
upstream will have such name, never. So this is not an issue. In this
specific case, you would have "type" and "cf_type", which is not a problem.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-16 20:00:23 UTC
Permalink
Frédéric Buclin wrote:
>> have it in mainline bugzilla for 3.0 (or 3.2). If it gets in to the
>> main bugzilla would this cause any issues for those of us that have
>> already implemented a custom field with the same name? Is this a
>> testcase that has been considered?
>
> All custom field names begin with "cf_". None of the fields
> implemented upstream will have such name, never. So this is not an
> issue. In this specific case, you would have "type" and "cf_type",
> which is not a problem.
Yes, but if I create a custom field with a label "Type" and values
"Enhancement" "Defect" "Task" "Meta" "Question" and "Feature" and start
using it, there will be a cf_type field in the database. When bug 9412
gets resolved there would be a "Type" field with a type field in the
database. What would I expect to do there (probably migrate my field
into the new supported one)?

Max appears to suggest at the end of 9412 that Type should be a custom
field that ships with bugzilla.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-16 21:47:31 UTC
Permalink
> Max appears to suggest at the end of 9412 that Type should be a custom
> field that ships with bugzilla.

This may be dangerous as all custom field names are of the form cf_foo
and we don't know which names have already been used. Official fields
will have a name which won't collide with those, though. We will
probably add an attribute to fields allowing us to enable/disable these
fields from editfields.cgi. Another example is the status whiteboard.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Kevin Benton
2007-01-16 18:08:25 UTC
Permalink
Bill Barry wrote:
>
>>> 2. a contrib patch to allow secure authenticated inbound emails
>>>
>>
>> This doesn't have to be contrib. I already have code that does
>> this, I just have to wait for copyright release on it. We have already
>> planned to do this.
>>
> How would you do this? Client certs? GPG?
> I have a script that will allow inbound email from the inside of our
> network (it works very much like fetchmail, in fact I bet it could be
> replaced with fetchmail), but it doesn't authenticate in any way. An
> authentication mechanism that anyone can use without getting in the
> way of normal email sending/recieving (through outlook and exchange)
> would be awesome (I could open the script up to the outside) but I
> haven't figured out how to do it.
>>
>>> 3. better use of the header links section (I think your own saved
>>> searches should go there:
>>>
>>
>> Some people have 50 saved searches.
>>
> So have the ability to show your saved searches in the header and/or
> footer in user prefs.
>>> 5. display the version in the footer on every page (pref bottom right
>>> in a float box that takes up no height)
>>>
>>
>> It's already in the header. Are you looking at bmo instead of
>> actual upstream?
>>
> Because I have replaced it in the header with a searchbox, I moved it
> to the footer. The header is much more valuable space than the footer
> and should be wisely used.
>
Hi Max,

I was just thinking - for those that have a high number of saved
searches, it might be useful to allow the user to specify that they want
their searches in a pull-down menu rather than taking up so much space
in the "saved searches" section of the header/footer. That would save a
bunch of space and still keep it at the top where it's most likely to be
used / needed. It would probably be best if users can configure whether
or not they see their saved searches in a pull-down and whether or not
they appear in the header, footer, or both. Of course, brainstorming a
bit, it might also be nice if users could group their saved searches so
they would not only appear in a certain order, but if pull-downs are
enabled, multiple pull-downs could be offered.

Kevin


--
Frédéric Buclin
2007-01-16 21:43:30 UTC
Permalink
> I was just thinking - for those that have a high number of saved searches, it
> might be useful to allow the user to specify that they want their searches in a
> pull-down menu rather than taking up so much space in the "saved searches"
> section of the header/footer.

You should first look at b.m.o. We already have a bug for it. :)


> course, brainstorming a bit, it might also be nice if users could group their
> saved searches so they would not only appear in a certain order, but if
> pull-downs are enabled, multiple pull-downs could be offered.

We also have a bug about ordering saved searches. ;)

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Kevin Benton
2007-01-16 21:50:43 UTC
Permalink
Frédéric Buclin wrote:
>> I was just thinking - for those that have a high number of saved
>> searches, it might be useful to allow the user to specify that they
>> want their searches in a pull-down menu rather than taking up so much
>> space in the "saved searches" section of the header/footer.
>
> You should first look at b.m.o. We already have a bug for it. :)
>
>> course, brainstorming a bit, it might also be nice if users could
>> group their saved searches so they would not only appear in a certain
>> order, but if pull-downs are enabled, multiple pull-downs could be
>> offered.
>
> We also have a bug about ordering saved searches. ;)
You're right - I should have looked first - I'm glad I'm not the only
one thinking this stuff up 8-) :-P 8-)

--
Frédéric Buclin
2007-01-16 21:57:30 UTC
Permalink
> I'm glad I'm not the only one thinking this stuff up


Who said the other ones requesting this feature are sane persons? :-D
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Kevin Benton
2007-01-16 21:59:50 UTC
Permalink
Frédéric Buclin wrote:
>> I'm glad I'm not the only one thinking this stuff up
>
>
> Who said the other ones requesting this feature are sane persons? :-D
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton-***@public.gmane.org>
>
>
>
LOL :-P 8-)

--
Gervase Markham
2007-01-18 20:51:26 UTC
Permalink
Kevin Benton wrote:
> I was just thinking - for those that have a high number of saved
> searches, it might be useful to allow the user to specify that they want
> their searches in a pull-down menu rather than taking up so much space
> in the "saved searches" section of the header/footer.

I tried this on a mock-up once. I remember Myk had some usability issues
with it.

> That would save a
> bunch of space and still keep it at the top where it's most likely to be
> used / needed.

But makes each saved search a click - scroll - click instead of just a
click. And it's worse with a longer list.

> It would probably be best if users can configure whether
> or not they see their saved searches in a pull-down and whether or not
> they appear in the header, footer, or both.

That's the second or third time in this thread that someone has
suggested making a UI feature "configurable" in case some people don't
like it. We are in danger of getting Mozilla Suite-itis here. We should
use established usability principles to work out what's best, and do
that. That's why, for example, we've resisted having comments in
non-fixed-width fonts or wider than 80 chars.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Max Kanat-Alexander
2007-01-16 22:59:31 UTC
Permalink
On Tue, 16 Jan 2007 09:11:52 -0500 Bill Barry <after.fallout-***@public.gmane.org>
wrote:
> > This doesn't have to be contrib. I already have code that
> > does this, I just have to wait for copyright release on it. We have
> > already planned to do this.
> >
> How would you do this? Client certs? GPG?

GPG. As I said, I've already written the code.

Then, after GPG, we will be implementing a challenge-response
mechanism for non-GPG emails. (Sort of like how you confirm for
subscribing to a mailing list.)

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-17 00:08:28 UTC
Permalink
> Then, after GPG, we will be implementing a challenge-response
> mechanism for non-GPG emails. (Sort of like how you confirm for
> subscribing to a mailing list.)
>
I hadn't thought of that, good idea (put the authentication out to
whether or not the user can authenticate to their mail server)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-18 20:48:56 UTC
Permalink
Bill Barry wrote:
> 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412

I was working on a possible migration to Bugzilla the other day, and
recommended they combine their current "bug/enhancement" field with the
severity field, as Bugzilla has it, during the migration - i.e. that
Bugzilla's way is better than their way.

Despite what bug 9412 says, enhancements don't have a severity. They
have a priority, and they might have an estimate (in time-tracking) but
they don't have a severity. Splitting the field up in mainline Bugzilla
is, IMO, a mistake.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-18 22:10:48 UTC
Permalink
> Despite what bug 9412 says, enhancements don't have a severity. They
> have a priority, and they might have an estimate (in time-tracking)
> but they don't have a severity. Splitting the field up in mainline
> Bugzilla is, IMO, a mistake.
From bugzilla's documentation on a priority:
--
This field describes the importance and order in which a bug should be
fixed. This field is utilized by the programmers/engineers to prioritize
their work to be done. The available priorities range from *P1* (most
important) to *P5* (least important.)
--
Priorities describe what a *programmer* and/or his/her superiors feel
should be done, and a general order of how to do them.

While an enhancement does not have a severity in the usual sense of the
word (the impact that the defect has in its existing form as the report
is filed), the aspects of implementing an enhancement (a modification of
the system to allow a new use or better use of some system aspect) do
indeed have an impact on the system, and hence a risk assessment
including the details of how much an impact that enhancement will cause
justifies the severity of an enhancement.

Another aspect of bug 9412 is that there are bugs in bugzilla that are
neither defects (on the product itself) nor enhancements. In the current
system these items are hard to search for without implementing
specialized nomenclature (meta keyword, questions about
documentation/code/..., tasks to remember to test under a certain
configuration, etc.). These issues make it harder to switch from
bugzilla to bugzilla (or to any other issue tracker). By implementing a
standardized system for identifying these items we would make not only
the task of using multiple systems easier, but also the task of
migrating data between these systems easier.

In my opinion the Milestone field is a mistake. I think it would have
been superior to use special milestone bugs and dependencies to make it
very simple to see how multiple bugs are related. A milestone bug would
also have the added benefit of having a deadline.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-18 22:21:10 UTC
Permalink
Bill Barry wrote:
> Priorities describe what a *programmer* and/or his/her superiors feel
> should be done, and a general order of how to do them.

Right.

> While an enhancement does not have a severity in the usual sense of the
> word (the impact that the defect has in its existing form as the report
> is filed), the aspects of implementing an enhancement (a modification of
> the system to allow a new use or better use of some system aspect) do
> indeed have an impact on the system, and hence a risk assessment
> including the details of how much an impact that enhancement will cause
> justifies the severity of an enhancement.

Severity is not the result of a risk assessment on the impact of a fix.
It's a measurement of how much of a problem the bug is for how many
users. If the thing in question is a problem for users in that sense,
then fixing it isn't an enhancement.

> Another aspect of bug 9412 is that there are bugs in bugzilla that are
> neither defects (on the product itself) nor enhancements.

Such as what? And is Bugzilla actually appropriate for tracking them?

> In my opinion the Milestone field is a mistake. I think it would have
> been superior to use special milestone bugs and dependencies to make it
> very simple to see how multiple bugs are related. A milestone bug would
> also have the added benefit of having a deadline.

You could implement any bug grouping in terms of dependencies - we could
eliminate the OS field and have an "OS/2" tracking bug on which all OS/2
bugs depend. You would need to argue why Milestone is uniquely suitable
for abolishment and replacement in this way.

It would certainly make searching harder to do. How do you search for
bugs fixed in the last three releases? "Depends on bug 12342, 16536 and
19354". Hang on - or was it 19345? :-)

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-19 14:37:02 UTC
Permalink
> Severity is not the result of a risk assessment on the impact of a
> fix. It's a measurement of how much of a problem the bug is for how
> many users. If the thing in question is a problem for users in that
> sense, then fixing it isn't an enhancement.
If it is a change that allows a user to use the system in a way not
intended by the original requirements document, then it needs design
decisions to be made about it (as opposed to just giving it to a
developer to fix it the way the bug describes) and is an enhancement.

Another difference is that while a bug decribes a problem with some
known (at the time of writing the bug, perhaps not before) test case. An
enhancement on the other hand requires new test cases.
>
>> Another aspect of bug 9412 is that there are bugs in bugzilla that
>> are neither defects (on the product itself) nor enhancements.
>
> Such as what? And is Bugzilla actually appropriate for tracking them?
As that bug describes:
https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37

>
>> In my opinion the Milestone field is a mistake. I think it would have
>> been superior to use special milestone bugs and dependencies to make
>> it very simple to see how multiple bugs are related. A milestone bug
>> would also have the added benefit of having a deadline.
>
> You could implement any bug grouping in terms of dependencies - we
> could eliminate the OS field and have an "OS/2" tracking bug on which
> all OS/2 bugs depend. You would need to argue why Milestone is
> uniquely suitable for abolishment and replacement in this way.
I don't like, nor do I think OS and Hardware are particularly useful
either. They allow you to find more specific test cases, and make
triaging easier, but as single select fields their usefulness is
limited. I think it would work much better these were right underneath
the comment section and put in a label "Affects" which would then put in
the comments "Affects OSxxxx on Hw####" as the last bit of text in each
comment where a user selects something from the lists. I argue that they
don't make searching for bugs any easier because I see it happen where
people cannot find duplicate bugs because they consistently search for
"Windows XP / All" or "OS X / Macintosh" when they are looking for a bug
that affects all systems, or has only ever before been seen in "Linux / PC"

Milestone is uniquely suited (compared to hardware and OS) because it is
truly a single select field (rather than a field that due to another
long standing bug in Bugzilla only allows one value:
https://bugzilla.mozilla.org/show_bug.cgi?id=9468). Milestone is not
unique compared to Version and if it was designed to be the version
fixed in (as Dave said in another reply on this thread) it would be very
useful (but again both could very easily be replaced with dependencies
on specially typed bugs).
>
> It would certainly make searching harder to do. How do you search for
> bugs fixed in the last three releases? "Depends on bug 12342, 16536
> and 19354". Hang on - or was it 19345? :-)
Aliases, we already have them to make finding special bugs easier, why
not use them:
blocks "next_rel"
blocks "future"
blocks "Bugzilla 3.2"
depends on "reflow"
depends on "gecko_units"
depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18"
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Kevin Benton
2007-01-19 16:49:25 UTC
Permalink
Bill Barry wrote:
>
>> Severity is not the result of a risk assessment on the impact of a
>> fix. It's a measurement of how much of a problem the bug is for how
>> many users. If the thing in question is a problem for users in that
>> sense, then fixing it isn't an enhancement.
> If it is a change that allows a user to use the system in a way not
> intended by the original requirements document, then it needs design
> decisions to be made about it (as opposed to just giving it to a
> developer to fix it the way the bug describes) and is an enhancement.
>

Since the severities are now customizable, it's possible to set your own
definitions and include things like Enhancement is Business Critical,
Enhancement is Needed, Enhancement is Wanted, etc... That would allow
your customer to specify how important the enhancement request was to them.

> Another difference is that while a bug decribes a problem with some
> known (at the time of writing the bug, perhaps not before) test case.
> An enhancement on the other hand requires new test cases.

A well-written enhancement request includes an adequate specification,
thus providing a minimal set of test cases. Many times, however, when
an enhancement request is made, there isn't enough information available
to make a good (set of) test case(s). As I see it, determining good
test cases for an enhancement request requires that it's feasible to
write the enhancement first, then if so, write the test cases.

>>
>>> Another aspect of bug 9412 is that there are bugs in bugzilla that
>>> are neither defects (on the product itself) nor enhancements.
>>
>> Such as what? And is Bugzilla actually appropriate for tracking them?
> As that bug describes:
> https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37
>
... errata, documentation tracking issues, status trackers, ...
>>
>>> In my opinion the Milestone field is a mistake. I think it would
>>> have been superior to use special milestone bugs and dependencies to
>>> make it very simple to see how multiple bugs are related. A
>>> milestone bug would also have the added benefit of having a deadline.
>>
>> You could implement any bug grouping in terms of dependencies - we
>> could eliminate the OS field and have an "OS/2" tracking bug on which
>> all OS/2 bugs depend. You would need to argue why Milestone is
>> uniquely suitable for abolishment and replacement in this way.
> I don't like, nor do I think OS and Hardware are particularly useful
> either. They allow you to find more specific test cases, and make
> triaging easier, but as single select fields their usefulness is
> limited. I think it would work much better these were right underneath
> the comment section and put in a label "Affects" which would then put
> in the comments "Affects OSxxxx on Hw####" as the last bit of text in
> each comment where a user selects something from the lists. I argue
> that they don't make searching for bugs any easier because I see it
> happen where people cannot find duplicate bugs because they
> consistently search for "Windows XP / All" or "OS X / Macintosh" when
> they are looking for a bug that affects all systems, or has only ever
> before been seen in "Linux / PC"
>

We agree to disagree then. When your QA team requires that a bug is
filed per impacted Hardware & OS so that their work is tracked in each
bug separately, then OS and Hardware as single-select fields are very
meaningful. There's nothing wrong with adding an OS or Hardware label
that others agree includes a group of platforms.

> Milestone is uniquely suited (compared to hardware and OS) because it
> is truly a single select field (rather than a field that due to
> another long standing bug in Bugzilla only allows one value:
> https://bugzilla.mozilla.org/show_bug.cgi?id=9468). Milestone is not
> unique compared to Version and if it was designed to be the version
> fixed in (as Dave said in another reply on this thread) it would be
> very useful (but again both could very easily be replaced with
> dependencies on specially typed bugs).

I agree that it seems that Milestone could be better if it were directly
tied to the versions table. I also agree that there are times when it's
useful to track found_in_rev versus fixed_in_rev versus
planned_for_rev. I've been side-tracked from finishing up my impact
table, however, one of my implementations in that update is to
incorporate versions at the component level. Here, we actually track
all three of these version fields. Milestones has been changed to
planned_for_rev. Version has been changed to found_in_rev. A new field
(fixed_in_rev) was added so we know exactly when a version was fixed,
not just when was it originally planned for. We're considering
incorporating also_in_revs so we know when a fix is applied to a number
of versions.

>>
>> It would certainly make searching harder to do. How do you search for
>> bugs fixed in the last three releases? "Depends on bug 12342, 16536
>> and 19354". Hang on - or was it 19345? :-)
> Aliases, we already have them to make finding special bugs easier, why
> not use them:
> blocks "next_rel"
> blocks "future"
> blocks "Bugzilla 3.2"
> depends on "reflow"
> depends on "gecko_units"
> depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18"

Because you can only have one alias pointing to a single bug in the
entire DB. Using a milestone, keyword or flag makes more sense.

--
bill barry
2007-01-20 13:09:39 UTC
Permalink
> It would certainly make searching harder to do. How do you search for bugs
> fixed in the last three releases? "Depends on bug 12342, 16536 and 19354".
> Hang on - or was it 19345? :-)
>
> Aliases, we already have them to make finding special bugs easier, why not
> use them:
> blocks "next_rel"
> blocks "future"
> blocks "Bugzilla 3.2"
> depends on "reflow"
> depends on "gecko_units"
> depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18"
>
>
> Because you can only have one alias pointing to a single bug in the entire
> DB. Using a milestone, keyword or flag makes more sense.
>

Why would you need an alias to point to more than one bug? There should only
be one bug for a release of a particular product. I am not sure I grasp your
point.
Gervase Markham
2007-01-20 16:33:05 UTC
Permalink
Kevin Benton wrote:
> Since the severities are now customizable, it's possible to set your own
> definitions and include things like Enhancement is Business Critical,
> Enhancement is Needed, Enhancement is Wanted, etc...

But those are not severities, they are priorities (which are also
customisable.) "Business Critical", for example, is clearly a priority,
not a severity.

>>> Such as what? And is Bugzilla actually appropriate for tracking them?
>> As that bug describes:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37
>>
> ... errata, documentation tracking issues, status trackers, ...

Errata is another name for bugs. Documentation tracking issues is a
euphemism for bugs in the documentation. Bugzilla tracks these things
fine today for loads of people.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-18 22:22:22 UTC
Permalink
> In my opinion the Milestone field is a mistake. I think it would have
> been superior to use special milestone bugs and dependencies to make it
> very simple to see how multiple bugs are related. A milestone bug would
> also have the added benefit of having a deadline.

Milestones *are* useful, much more than all these meta bugs which are
often created because some developer or user is interested in keeping
track on some specific feature and wants a way to quickly find them. But
now that we can tag bugs, this makes meta bugs pretty obsolete in most
cases.

Moreover, you always have to remember to block the "milestone" bug, and
more important, to remember what its ID or alias is. Pretty annoying and
prone to errors.

About deadlines, you can add milestones such as "2007-01-18" if you want to.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Dave Williss
2007-01-18 22:46:04 UTC
Permalink
Bill Barry wrote:
> In my opinion the Milestone field is a mistake. I think it would have
> been superior to use special milestone bugs and dependencies to make
> it very simple to see how multiple bugs are related. A milestone bug
> would also have the added benefit of having a deadline.
We (at my company) use the Target Milestone for two different things:

* To indicate what version a bug was fixed in. For example, there
may be a bug that was reported in version 1.0 but nobody got around to
fixing it until 2.1. In this sense, the target is never set until the
bug is resolved. We also have a script that runs every night via cron
to check the database and annoy people who forget to set the target
milestone when resolving bugs. If I felt like customizing our templates
locally, I'd rename it "Resolved In:"

* To indicate what version we'd _like_ something fixed, which is what
I believe the field was actually intended for. For that, I agree with
Bill that a special Milestone bug dependency would be better.

We also use the Status Whiteboard to keep track of clients who need to
be notified via email when something is fixed. We can't use the cc list
for this because 1) our bugzilla is on a private LAN with no connection
to the internet for security reasons. 2) If we add all our clients as
users, they'd show up not only on the CC list but on the Assigned To and
QC Contact lists. We'd really like a way to add a custom field that
worked like the CC list but pulled from a different user table (actually
an SQL query from the actual client database would be _really_ nice) and
just didn't try to send out the email. However, now I'm digressing into
wish-list sorts of things.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-18 20:45:50 UTC
Permalink
Frédéric Buclin wrote:
> Currently no strong post-3.0 objective. We will discuss about this as
> soon as 3.0 RC1 is released and the trunk open again for development.
> One direction is to make Bugzilla usable on small devices.

Do we have strong use cases for this, in terms of actual people saying
"Yes, I would use Bugzilla from my handheld if I could"?

>> Is the "personalities" project still a factor?
>
> This project is pretty dead AFAIK. gerv is the one who was working on
> it. He could tell us more about it.

It can be used in its current state; more work would improve it.

The idea is to work out who our target audience is. If we are agreed
that we've got it, then we're done. If we're not agreed, we need to
think about it some more.

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-18 21:35:40 UTC
Permalink
> Do we have strong use cases for this, in terms of actual people saying
> "Yes, I would use Bugzilla from my handheld if I could"?

If the inbound email interface ends up working well enough, I would
rather use that; but yes, I would use bugzilla on my handheld (and so
would 6 others at Stellar; we all already receive the bugmail on our
phones, the ability to modify a bug while not in front of a computer is
a welcome opportunity).
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Kevin Benton
2007-01-16 00:35:20 UTC
Permalink
Frédéric Buclin wrote:
>> Approximately half of you mentioned placement of the comment box.
>> Perhaps this issue can be more easily addressed (with concensus) than
>> other issues?
>
> This issue is specific to b.m.o. Has nothing to do with Bugzilla 3.0.
>
>
>> Has anyone tested a side-by-side arrangement? That is, have comments
>> start at the top of page in a scrollable column of their own next to
>> the labels?
>>
>> I'd appreciate your comments on an example I've mocked up
>
>
> I have to scroll horizontally to see comments. Meaning that you should
> narrow the left column, meaning that you would have to scroll even
> more to see all fields. Not sure that's a good idea.
>
I agree with you, LpSolit - I don't want to be forced to make my
Bugzilla browser window full-screen just so I can see comments without
horizontally scrolling. I also feel that white space on the screen is a
good thing

It just occurred to me - we're not using an anchor index (list) at all.
An anchor index at the top of the bug display would help users jump to
the appropriate section and does not have any negative impact on
testing. The only question I have is if the user is interactively
editing and they click on an anchor, do they clear their input or does
it remain where it was? That answer may be browser-dependent. Just
thinking out loud :)

At some point, we may want to consider multiple bug views through a
navigation bar on the LHS. This would give users the ability to see
specific pre-defined views that don't necessarily display all the
fields, comments or activity. There is value in limiting the view to
"just the facts" that I need to get my job done. I think each of us
would agree that few people want everything in the order given depending
on what they're doing. There are times when we take the role of
developer, QA, reporter, etc. Depending on our role, we care about
different parts of the bug first. RT actually does a fair job of
implementing this through tabbed views of bugs.

Kevin

--
Bill Barry
2007-01-16 01:15:34 UTC
Permalink
Kevin Benton wrote:
> Frédéric Buclin wrote:
>>> Approximately half of you mentioned placement of the comment box.
>>> Perhaps this issue can be more easily addressed (with concensus)
>>> than other issues?
>>
>> This issue is specific to b.m.o. Has nothing to do with Bugzilla 3.0.
>>
>>
>>> Has anyone tested a side-by-side arrangement? That is, have
>>> comments start at the top of page in a scrollable column of their
>>> own next to the labels?
>>>
>>> I'd appreciate your comments on an example I've mocked up
>>
>>
>> I have to scroll horizontally to see comments. Meaning that you
>> should narrow the left column, meaning that you would have to scroll
>> even more to see all fields. Not sure that's a good idea.
>>
> I agree with you, LpSolit - I don't want to be forced to make my
> Bugzilla browser window full-screen just so I can see comments without
> horizontally scrolling. I also feel that white space on the screen is
> a good thing
>
> It just occurred to me - we're not using an anchor index (list) at
> all. An anchor index at the top of the bug display would help users
> jump to the appropriate section and does not have any negative impact
> on testing. The only question I have is if the user is interactively
> editing and they click on an anchor, do they clear their input or does
> it remain where it was? That answer may be browser-dependent. Just
> thinking out loud :)
>
> At some point, we may want to consider multiple bug views through a
> navigation bar on the LHS. This would give users the ability to see
> specific pre-defined views that don't necessarily display all the
> fields, comments or activity. There is value in limiting the view to
> "just the facts" that I need to get my job done. I think each of us
> would agree that few people want everything in the order given
> depending on what they're doing. There are times when we take the
> role of developer, QA, reporter, etc. Depending on our role, we care
> about different parts of the bug first. RT actually does a fair job
> of implementing this through tabbed views of bugs.
I'd rather the navbar across the top and to include activity log and
votes. Menus down the sides seem to always waste space underneath them
We would only want a very limited number of such views though.
I'd say 6 max and I would try to stick to 5 if it wasn't a big deal:
edit (pretty much current HEAD)
bmo style
view (something like kde bugzilla, except even simpler when you first
look at it; give it client side tabs to get at functionality, like the
tabs at the bottom of https://bugzilla.mozilla.org/attachment.cgi?id=232603)
print
xml (this wouldn't show up in the tab)

And the default should be controlled by a user pref.

If we are going to worry about the role of the user, it would probably
be good to have a different my bugs link for different users. QA people
(at least here at stellar financial) seem to almost never have anything
useful in "My bugs" because they need to deal with the bugs later in the
cycle(when resolved and close to resolved).
>
> Kevin
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout-***@public.gmane.org>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Frédéric Buclin
2007-01-16 09:46:21 UTC
Permalink
> I'd rather the navbar across the top and to include activity log and
> votes. Menus down the sides seem to always waste space underneath them
> We would only want a very limited number of such views though.


Not sure this will happen in the near future. Several of us prefer to
see all the data in the same page, without having to go from tab to tab.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-16 13:38:00 UTC
Permalink
Frédéric Buclin wrote:
>> I'd rather the navbar across the top and to include activity log and
>> votes. Menus down the sides seem to always waste space underneath them
>> We would only want a very limited number of such views though.
>
>
> Not sure this will happen in the near future. Several of us prefer to
> see all the data in the same page, without having to go from tab to tab.
We already do go to other pages to see the activity log and votes (I
prefer to see everything on one page as well). This would mean that
instead of the links in related actions section they would be tabs.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout-***@public.gmane.org>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Gervase Markham
2007-01-18 20:52:57 UTC
Permalink
Bill Barry wrote:
> We already do go to other pages to see the activity log and votes

Yes, but they are very infrequently viewed. I can count the number of
times I've looked at either in the past year on the fingers of one hand.

If things are too complex for some users, make them a simpler template
with just the fields they care about, triggered by group membership.

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Myk Melez
2007-01-18 22:58:03 UTC
Permalink
Gervase Markham wrote:
> Bill Barry wrote:
>> We already do go to other pages to see the activity log and votes
>
> Yes, but they are very infrequently viewed. I can count the number of
> times I've looked at either in the past year on the fingers of one hand.
I can't, for activity anyway. I look at it regularly, especially when
triaging bugs. But maybe I'm an exceptional case.

In any case, I'm not particularly interested in where the links are, but
I would like the actual information to be mixed in with the comments,
since it often provides context for those comments.

-myk

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Wayne Mery
2007-01-19 03:08:50 UTC
Permalink
On 1/18/2007 5:58 PM, Myk Melez wrote:
> Gervase Markham wrote:
>> Bill Barry wrote:
>>> We already do go to other pages to see the activity log and votes
>>
>> Yes, but they are very infrequently viewed. I can count the number of
>> times I've looked at either in the past year on the fingers of one hand.
> I can't, for activity anyway. I look at it regularly, especially when
> triaging bugs. But maybe I'm an exceptional case.
>
> In any case, I'm not particularly interested in where the links are, but
> I would like the actual information to be mixed in with the comments,
> since it often provides context for those comments.
>
> -myk

from a triage standpoint, my use of activity is ~10-20%, which
definitely is more than two hands, a nose and two feet :) - the reason
being you often want to see the reason/description of why a change
(summary, dependency, status etc) was made.

For a developer or manager I have not doubt it's close to zero.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Luis Villa
2007-01-19 03:14:14 UTC
Permalink
On 1/18/07, Wayne Mery <vseerror-h/13/***@public.gmane.org> wrote:
> On 1/18/2007 5:58 PM, Myk Melez wrote:
> > Gervase Markham wrote:
> >> Bill Barry wrote:
> >>> We already do go to other pages to see the activity log and votes
> >>
> >> Yes, but they are very infrequently viewed. I can count the number of
> >> times I've looked at either in the past year on the fingers of one hand.
> > I can't, for activity anyway. I look at it regularly, especially when
> > triaging bugs. But maybe I'm an exceptional case.
> >
> > In any case, I'm not particularly interested in where the links are, but
> > I would like the actual information to be mixed in with the comments,
> > since it often provides context for those comments.
> >
> > -myk
>
> from a triage standpoint, my use of activity is ~10-20%, which
> definitely is more than two hands, a nose and two feet :) - the reason
> being you often want to see the reason/description of why a change
> (summary, dependency, status etc) was made.
>
> For a developer or manager I have not doubt it's close to zero.

A good manager uses it all the time, for the same reason you give for
a triager's use of it. I'd venture to say a good developer should use
it too, since a good developer should understand why something is high
or low priority, and who made it that way, but that may be too much to
ask ;)

Luis (once a manager, though admittedly not a good one ;)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Bill Barry
2007-01-16 00:15:11 UTC
Permalink
Wayne Mery wrote:
> Approximately half of you mentioned placement of the comment box.
> Perhaps this issue can be more easily addressed (with concensus) than
> other issues?
>
> However, I submit even 2.22's top placement (which for those with
> editbug seems to be the concensus preference) is not ideal. I must
> scroll to see the first or most recent comments or get past
> attachments section (which I rarely need to see) and then scroll back
> up to change any fields. I'd really rather see everything at once, or
> at least not have to scroll much more than one page.
>
> Has anyone tested a side-by-side arrangement? That is, have comments
> start at the top of page in a scrollable column of their own next to
> the labels?
>
> I'd appreciate your comments on an example I've mocked up
> http://i13.tinypic.com/2wehvg7.png Can it be mocked up on landfill?
I remember somewhere before a discussion about making it two columns
like that, but the central issue was that the two pages would be too
wide for a bugzilla page. The reason it is too wide in many cases is
that several of the fields can potentially have long values (product,
component, assigned to and milestone) and that the attachments table
spans the entire page (and sometimes has long names there, like a full
cvs file path)
>
>
> For reporters and the like who don't have edit privs - 2.23's bottom
> placement might encourage users to read the latest comments before
> commenting themselves. OTOH 2.22's top placement, below attachments
> and above comment 0, encourages nothing IMO - reading of the
> reporter's STR or the last comments. So perhaps 2.23's setup is better.
The placement at the bottom is only at bmo, (and it is good there, I
think). However, for a general installation, the comment box placement
at the bottom is not something I would want. For a clean idea of what
2.23 looks like, visit: http://landfill.bugzilla.org/bugzilla-tip
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=after.fallout-***@public.gmane.org>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>
Continue reading on narkive:
Loading...