Sebastian Pipping posted on Tue, 02 Mar 2010 01:02:05 +0100 as excerpted:

> Quoting Ioannis Aslanidis <aslanidis@gmail.com>:
>> I would prefer to keep the keyword for Bugday Members to administer.
>
> I don't think that sending mails would work well. If you want extra
> control/QA for bugday team members I would propose two different
> keywords: one for bugday candidates and one for confirmed bugday bugs.
>
> Any dev could mark bugs as candidates easily and without delays while
> you could still reserve acknoledgement to you.

... And here I'm proposing three:

BUGDAY (nomination)
BUGDAY-ACCEPTED (or whatever is thought appropriate)
NOBUGDAY (or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...)

The latter would be for nominated bugs that were declined as inappropriate
for whatever reason, to help prevent them being nominated again.
Presumably there'd be a comment added explaining why as well, but the
keyword would be what shows up in someone's face if they're thinking about
keywording it BUGDAY.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Mon, Mar 1, 2010 at 5:09 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Sebastian Pipping posted on Tue, 02 Mar 2010 01:02:05 +0100 as excerpted:
>
>> Quoting Ioannis Aslanidis <aslanidis@gmail.com>:
>>> I would prefer to keep the keyword for Bugday Members to administer.
>>
>> I don't think that sending mails would work well. If you want extra
>> control/QA for bugday team members I would propose two different
>> keywords: one for bugday candidates and one for confirmed bugday bugs.
>>
>> Any dev could mark bugs as candidates easily and without delays while
>> you could still reserve acknoledgement to you.
>
> ... And here I'm proposing three:
>
> BUGDAY * * * * *(nomination)
> BUGDAY-ACCEPTED (or whatever is thought appropriate)
> NOBUGDAY * * * *(or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...)

I think the last one is over-engineering a bit; bugzilla keywords are
not permanent so this will likely not help as much as one may think in
practice. Old bugday keywords are visible in the activity trail.

-A

>
> The latter would be for nominated bugs that were declined as inappropriate
> for whatever reason, to help prevent them being nominated again.
> Presumably there'd be a comment added explaining why as well, but the
> keyword would be what shows up in someone's face if they're thinking about
> keywording it BUGDAY.
>
> --
> Duncan - List replies preferred. * No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." *Richard Stallman
>
>
>

On 03/02/10 02:09, Duncan wrote:
> ... And here I'm proposing three:
>
> BUGDAY (nomination)
> BUGDAY-ACCEPTED (or whatever is thought appropriate)
> NOBUGDAY (or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...)
>
> The latter would be for nominated bugs that were declined as inappropriate
> for whatever reason, to help prevent them being nominated again.
> Presumably there'd be a comment added explaining why as well, but the
> keyword would be what shows up in someone's face if they're thinking about
> keywording it BUGDAY.

I agree that it would be useful.

Especially if we have bugs where an assignee wants to take care of the
bug himself (including his own scheduling), we could run into
bugday-keyword wars:

1) add keyword
2) remove keyword
3) overlook previous removal
4) goto <1>

To make naming a bit more consistent, how about:
- BUGDAY-CANDIDATE
- BUGDAY-ACCEPTED
- BUGDAY-REFUSED

They're a bit long but I think it's worth to not have them crippled down
to stuff like "BDYES", "BDNO" and "BDMAYBE".



Sebastian

On 03/02/10 02:32, Alec Warner wrote:
>> BUGDAY (nomination)
>> BUGDAY-ACCEPTED (or whatever is thought appropriate)
>> NOBUGDAY (or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...)
>
> I think the last one is over-engineering a bit; bugzilla keywords are
> not permanent

How are they not permanent?



Sebastian

>>>>> On Tue, 02 Mar 2010, Sebastian Pipping wrote:

> To make naming a bit more consistent, how about:
> - BUGDAY-CANDIDATE
> - BUGDAY-ACCEPTED
> - BUGDAY-REFUSED

> They're a bit long but I think it's worth to not have them crippled
> down to stuff like "BDYES", "BDNO" and "BDMAYBE".

This looks like overkill to me. One keyword should be enough, and for
supplementary information "Status Whiteboard" could be used.

Ulrich

On 02/03/10 13:17, Ulrich Mueller wrote:






On Tue, 02 Mar 2010, Sebastian Pipping wrote:









To make naming a bit more consistent, how about:
- BUGDAY-CANDIDATE
- BUGDAY-ACCEPTED
- BUGDAY-REFUSED





They're a bit long but I think it's worth to not have them crippled
down to stuff like "BDYES", "BDNO" and "BDMAYBE".



This looks like overkill to me. One keyword should be enough, and for
supplementary information "Status Whiteboard" could be used.

Ulrich



I agree.* Simply having the BUGDAY
keyword should be sufficient, and more information can be provided
elsewhere in the report.



--Zach

On 03/01/10 22:17, Ioannis Aslanidis wrote:
> getting control of bugday.gentoo.org and be able to upload our own
> content would be great.

The current page is said to generate one XML request per bug listed on
the page for each request. From my experience trying to remove bugs
from that page yesterday(?) (through clicking on "remove" buttons) I
have the impression that it's true: Du to page reload times the site in
it's current form is unusable in the very sense of the word.

Ideas I have on a rather simple rewrite:

- Split the bugday website into two pages:
- Page "Open bugs" showing
- open bugday-keyworded bugs (with date of the latest bugday)
in randomized order
- Page "Closed bugs" showing
- closed bugday-keyworded bugs (with date of the latest bugday)
in some sorted order
- a ranking with closed bugs per participant
(as that may not be the assignee such information could
maybe be encoding into the status whiteboard, somewhere
we can query it from easily if whiteboard fits for that)

- Do one search request to bugzilla internally, only.
Should be possible as we're now asking bugzilla for the list
of bugs instead of asking for details on a list we pass in.

- Simple caching of bugzilla requests for 10 seconds or so.
Should not hurt the bugday experience much and reduce load
further.

I could imagine that an ugly prototype with rough-edges of that could
take two days in plain Python. At the moment I cannot say when and if I
have these two days, but maybe someone else with time is fire and flame
for it by now?



Sebastian

On 03/02/10 20:28, Nathan Zachary wrote:
>> This looks like overkill to me. One keyword should be enough, and for
>> supplementary information "Status Whiteboard" could be used.
>>
> I agree. Simply having the BUGDAY keyword should be sufficient, and
> more information can be provided elsewhere in the report.

If more than one keyword is commonly considered overkill I would at
least request the whiteboard for it: "somewhere in the report" involves
more than zero searching for it.



Sebastian

On 02/03/10 13:39, Sebastian Pipping wrote:

On 03/02/10 20:28, Nathan Zachary wrote:



This looks like overkill to me. One keyword should be enough, and for
supplementary information "Status Whiteboard" could be used.



I agree. Simply having the BUGDAY keyword should be sufficient, and
more information can be provided elsewhere in the report.



If more than one keyword is commonly considered overkill I would at
least request the whiteboard for it: "somewhere in the report" involves
more than zero searching for it.



Sebastian



Point taken, and I agree.



--Zach

On Tue, Mar 2, 2010 at 11:36 AM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 03/01/10 22:17, Ioannis Aslanidis wrote:
>> getting control of bugday.gentoo.org and be able to upload our own
>> content would be great.
>
> The current page is said to generate one XML request per bug listed on
> the page for each request. *From my experience trying to remove bugs
> from that page yesterday(?) (through clicking on "remove" buttons) I
> have the impression that it's true: Du to page reload times the site in
> it's current form is unusable in the very sense of the word.
>
> Ideas I have on a rather simple rewrite:
>
> *- Split the bugday website into two pages:
> * - Page "Open bugs" showing
> * * - open bugday-keyworded bugs (with date of the latest bugday)
> * * * in randomized order
> * - Page "Closed bugs" showing
> * * - closed bugday-keyworded bugs (with date of the latest bugday)
> * * * in some sorted order
> * * - a ranking with closed bugs per participant
> * * * (as that may not be the assignee such information could
> * * * maybe be encoding into the status whiteboard, somewhere
> * * * we can query it from easily if whiteboard fits for that)
>
> *- Do one search request to bugzilla internally, only.
> * Should be possible as we're now asking bugzilla for the list
> * of bugs instead of asking for details on a list we pass in.
>
> *- Simple caching of bugzilla requests for 10 seconds or so.
> * Should not hurt the bugday experience much and reduce load
> * further.

I would recommend not hardcoding 10 seconds; but otherwise caching is good

>
> I could imagine that an ugly prototype with rough-edges of that could
> take two days in plain Python. *At the moment I cannot say when and if I
> have these two days, but maybe someone else with time is fire and flame
> for it by now?
>
>
>
> Sebastian
>
>