Page MenuHomePhabricator

RT tickets hide status information from volunteers and staff alike
Closed, ResolvedPublic

Description

Status information for bug 29550 is apparently hiding on an RT ticket, which can't be seen by volunteers, staff, or anybody else who doesn't have a login on the private RT system.

This makes it harder to find out what's going on or get feedback; if ops people are updating the RT ticket we have no way of knowing, and then they get annoyed when we ask them for updates. :)


Version: unspecified
Severity: normal
URL: http://rt.wikimedia.org/

Details

Reference
bz30413

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:55 PM
bzimport set Reference to bz30413.
bzimport added a subscriber: Unknown Object (MLST).

Releasing block of bug 29550 which is about migrating TestSwarm from toolserver to a new server.

(In reply to comment #0)

Status information for bug 29550 is apparently hiding on an RT ticket, which
can't be seen by volunteers, staff, or anybody else who doesn't have a login
on
the private RT system.

This makes it harder to find out what's going on or get feedback; if ops
people
are updating the RT ticket we have no way of knowing, and then they get
annoyed
when we ask them for updates. :)

What do you propose as a resolution to this bug? As I understand it, rt.wikimedia.org was envisioned primarily as a place for ops to put non-public information (mostly server quotes, I guess). Then its use gradually expanded. Now, occasionally a bug's status will be unclear due to the closed (private) nature of rt.wikimedia.org. This doesn't happen too often, but this is a legitimate bug.

I'm not sure there's a good resolution to this bug, though. Is there a path forward for this bug?

There are a few options that I see:

  • continue with the current setup;
  • open rt.wikimedia.org further (allow volunteers to have accounts and act as liaisons, I suppose); and/or
  • restrict the use of rt.wikimedia.org to only sensitive information and move everything else to Bugzilla.

I have no idea how tenable any of these ideas are or if there's a better option available to resolve this bug.

MZMcBride: Something to bring up on the <ops@> mailing list?

(In reply to comment #3)

MZMcBride: Something to bring up on the <ops@> mailing list?

Sure, feel free. I'm not subscribed, but I assume you are?

Some more examples:
Bug 30413: "It would have been solved already if it had been filed in RT"
Bug 22622: More status hidden in RT. There were some claims of community “There's no action on it” vs “This is actively being worked in Ops” there.

As for fixes:
I would support moving everything to bugzilla, but ops would probably hate the idea, since I think they are also using it for some kind or time-tracking.

I don't think forcing some people to work as liasons between the two bugtrackers is the best way, but given that those following RT tickets will be a handful, it could work with some account creation with manual approbal .

However, I don't see why it can't be as open as bugzilla:
Allow everyone to fill bugs. And let them read/write the bug they opened.
If you are placing a tracking number, add a Private flag to the bug.
If you are interested in following a bug marked as private, you can get added as CC by someone with greater access.

I don't think there will be that much private information there that can't be public. Or perhaps they are using SSNs instead of usernames :)

If you are an employee who signed an NDA you can have RT accounts. No problem
at all. Please ask me to create them if you feel you are lacking one. And if you dont have a login to the web UI you can still just mail or forward ops-requests@ to create tickets. Note there is another ongoing request to provide "has-signed-NDA" or something similar as an LDAP flag to make it easier to handle access requests.

Everyone has been able to create tickets there for .. since i started working here afair.

(In reply to comment #7)

Everyone has been able to create tickets there for .. since i started working
here afair.

The problem is that after filing them, RT becomes a black hole. Unless you're properly CC'd, you don't receive all the replies to your ticket. And even if you have an account (like myself), sometimes it gets stolen by a user (or a queue?) and I can't even view my own ticket anymore.

I know we use RT for confidential things (and it's important to have a private place to discuss things sometimes), but for things that aren't private I really think RT does more harm than good.

It's the first time I hear that everyone can create tickets there.
Maybe they can but it's not documented anywhere and nobody knows it can do so?

(In reply to comment #4)

(In reply to comment #3)

MZMcBride: Something to bring up on the <ops@> mailing list?

Sure, feel free. I'm not subscribed, but I assume you are?

The issue about RT public availability is being discussed on the internal ops mailing list.

Thanks to Platonides using the email interface, there is now RT #4076 about publicly documenting RT usage. There hasn't been much progress yet though.

In general trying to understand the scope and use of RT, http://wikitech.wikimedia.org/view/RT states:
"The Wikimedia Operations team is using Request Tracker for managing day to day tasks." and "The Operations team is responsible for the technical infrastructure of Wikimedia sites: this includes the data centers, servers and network."

  • Bug 50866 has been marked as a duplicate of this bug. ***

I don't see anybody fixing "all tickets in RT should by default be read-only at least (excluding vendor/procurement tickets)" in RT itself, if that's what this ticket is mainly about.
See comment 6 and comment 13 for current situation and documentation.
Also see related discussion on [[mw:Project management tools/Review]].

This should be solved soon with the migration from RT to phabricator.

mark claimed this task.

This is being addressed by the migration towards Phabricator, and won't be fixable with RT.

I'd say we could actually mark this resolved with the migration.

MZMcBride changed the task status from Declined to Resolved.Dec 19 2014, 12:48 AM
MZMcBride set Security to None.