1112623 - Decommission dev-tech-xul (mozilla.dev.tech.xul)

Status: RESOLVED FIXED

(Infrastructure & Operations :: MOC: Service Requests, task)

Description

[Benjamin Smedberg]

The dev-tech-xul list is no longer useful; it is very low traffic and the traffic that does exist is all newcomer questions which would better be on ask.mozilla.org (almost none of the XUL technical experts are even on the list any more).

I posted a decommissioning proposal to the list last week and have not had any objections (any response at all, for that matter).

Please decommission this list.

Comment 1

[Gervase Markham [:gerv]]

Over to server-ops for implementation.

Gerv

Comment 2

[Benjamin Smedberg]

Dave, who owns next steps for this?

Comment 3

[Peter Radcliffe [:pir]]

The MOC. Requests should be put in Infrastructure & Operations :: MOC: Service requests to get seen.

Comment 4

[Dave Miller [:justdave]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Dave, who owns next steps for this?

Not me, I don't work in the area that deals with these anymore. We probably need to fix the default QA here.

(In reply to Peter Radcliffe [:pir] from comment #3)
> The MOC. Requests should be put in Infrastructure & Operations :: MOC:
> Service requests to get seen.

Actually, it needs to stay in the Discussion Forums component or it will get lost from other record keeping related to the forums.  MOC should be monitoring that component for bugs assigned to Server Ops.

Comment 5

[Peter Radcliffe [:pir]]

Monitoring server-ops complicates the process and makes things get missed, like this. We're actively trying to move away from that as a process because it doesn't scale. We've successfully done so with SVN/etc account requests coming in by getting child bugs into our queue where the originators want the main bug to stay in another queue.

We really, really, want to get away from monitoring server-ops and having requests come into MOC: Service requests to keep everything consistent and stop things from getting missed.

Comment 6

[Gervase Markham [:gerv]]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #4)
> Actually, it needs to stay in the Discussion Forums component or it will get
> lost from other record keeping related to the forums.  MOC should be
> monitoring that component for bugs assigned to Server Ops.

I was told a few months ago that this process was no longer acceptable, so I've been moving bugs over to Server Ops. 

I'm happy to do whatever helps the team, However, it does puzzle me why a query for "bugs assigned to [e-mail]" is a harder thing to track than "bugs in component MOC: Service Requests".

Gerv

Comment 7

[Peter Radcliffe [:pir]]

"Server Ops" as a group doesn't exist any more, this is part of the confusion. There were Server Ops bug queues, which are now defunct and removed, there is still a Server Ops user which still confuses matters.

it isn't about one vs the other being harder, it's about having just one. We want to have have one process for things being assigned to us which is bugs coming into our queues. It means we can monitor in one place, have one simple and consistent bugzilla search to check and get better metrics on what bugs come into the team from outside (sadly we need metrics to justify our existence and to get enough staff to cover the amount of work).

It really does make things easier for us if requests come into the MOC: service requests queue, so either a child bug or the main bug being put in Infrastructure & Operations :: MOC: Service Requests is strongly preferred.

Comment 8

[Gervase Markham [:gerv]]

I understand the need for one place, but given that requests will come in from a wide variety of teams, and relating to a wide variety of issues (many of which will have their own tracking in Bugzilla, which may not be available in the I&O product), then a standard assignee seems to me like it would make for less disruption to the rest of the company than a standard component. Still, there it is. Not worth changing now. I can work with the current process.

Gerv

Comment 9

[Peter Radcliffe [:pir]]

A standard assignee vanishes as soon as a member of the team takes the bug to work on it and it becomes invisible to the rest of the group.

In a team where people work in shifts and are not working normal days or hours along with normal business hours workers it can be very useful to be able to scan through all the bugs the team is working on and see that something they were waiting for has happened and a next step can be pushed through before the assignee is back in the office. A bug assigned to me, for example, won't get looked at after ~6pm UK time on Wednesday until Sunday morning otherwise (I work Sun-Wed).

Dropping assignees back to the default at the end of every shift is impractical so having them all in one component better for our workflow.

Comment 10

[Gervase Markham [:gerv]]

Good points. Thanks for the insight. I wonder if Bugzilla could better support your workflow. I'll have a think.

Gerv

Comment 11

[Vinh Hua [:vinh]]

removal checklist:
1. removed from mailman2.mail.scl3.mozilla.com

[[e-mail]3 ~]$ sudo /usr/lib/mailman/bin/list_lists | grep dev-tech-xul
                       dev-tech-xul - XUL (XML User-interface Language), the basis o

[[e-mail]3 ~]$ 
[[e-mail]3 ~]$  
[[e-mail]3 ~]$ sudo /usr/lib/mailman/bin/rmlist dev-tech-xul
Not removing archives.  Reinvoke with -a to remove them.
Removing list info
[[e-mail]3 ~]$ sudo /usr/lib/mailman/bin/list_lists | grep dev-tech-xul
[[e-mail]3 ~]$ 



2. emailed giganews 

3. Verified that the group is no longer listed on https://lists.mozilla.org/listinfo 

4. Have Gerv remove the listing of the group from https://www.mozilla.org/en-US/about/forums/   <-- is this required :gerv ?