Closed
Bug 843254
Opened 12 years ago
Closed 11 years ago
[research] no more pto for r1cky
Categories
(support.mozilla.org :: General, defect, P1)
support.mozilla.org
General
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: willkg, Assigned: rrosario)
Details
(Whiteboard: u=everyone c=general p=1000 s=2013.backlog)
We joke about how every time r1cky goes on PTO, everything catches on fire. But it's not really a joke--it's true.
I think we should write a script that spiders the PTO system and rejects all future PTO requests.
Comment 1•12 years ago
|
||
Who's Ricky?
Comment 2•12 years ago
|
||
This is going to mean a lot of extra dev time. Estimating at 13 points.
Whiteboard: u=dev c=infrastructure p=13 s=2013.backlog
Comment 3•12 years ago
|
||
Would it be possible to change Ricky's position to "contractor"? Otherwise, his position as a full-time employee may give him serious HR leverage. That might need to be a separate blocker bug.
| Reporter | ||
Comment 4•12 years ago
|
||
I fear if we make him a contractor that he'll go somewhere else. Maybe instead we could trick him into indentured servitude? Or maybe someone should swab his cheek accidentally at the next team meeting and we could clone him several times. It could be like that movie Moon--we wouldn't tell the clone he was a clone.
Comment 5•12 years ago
|
||
Clearly this one needs more research, and we should get to it very, very, very soon.
Summary: no more pto for r1cky → [research] no more pto for r1cky
| Reporter | ||
Comment 6•12 years ago
|
||
I did some poking around and I think cloning is a non-trivial project with the current codebase. Maybe it'd be easier to just pass him off to Sheeri to set up replication to a slave?
cc:ing Sheeri for thoughts.
Whiteboard: u=dev c=infrastructure p=13 s=2013.backlog → u=everyone c=general p= s=2013.5
Comment 7•12 years ago
|
||
Frankly, this is better done in the code layer - just like you have to have a valid date to submit PTO, we should write in that if you are r1cky, you can't submit PTO more than 0 hours per day.
Deleting the records once they're already in is a bad idea - there's a record in the logs of r1cky actually requesting time off. Best to make sure it never makes it to the database, and the logs.
| Assignee | ||
Comment 8•12 years ago
|
||
I haven't been able to reproduce. Can you provide detailed steps?
Status: NEW → UNCONFIRMED
Ever confirmed: false
| Assignee | ||
Comment 9•12 years ago
|
||
I think we need to move this to the backlog to discuss further.
Whiteboard: u=everyone c=general p= s=2013.5 → u=everyone c=general p= s=2013.backlog
| Assignee | ||
Comment 10•12 years ago
|
||
Q1 is in the past. Moving to the future.
Target Milestone: 2013Q1 → Future
Updated•12 years ago
|
Assignee: nobody → rrosario
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
| Assignee | ||
Comment 11•12 years ago
|
||
Making this one 1000pts because it's hard. We'll have to create a special sprint or maybe a ultramarathon for it.
Whiteboard: u=everyone c=general p= s=2013.backlog → u=everyone c=general p=1000 s=2013.backlog
Comment 12•12 years ago
|
||
Just create a special sprint with all the bugs that have ever and will ever be fixed. And assign r1cky to it.
Since the lifespan of all projects ever created and ever being created is close to infinity, I'd rather re-measure the points to being close to infinity. Unfortunately, my charset doesn't allow infinity signs here.
Updated•11 years ago
|
Severity: normal → blocker
| Assignee | ||
Comment 13•11 years ago
|
||
Hoping this goes unnoticed during the great triage of 2014.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
| Assignee | ||
Comment 15•11 years ago
|
||
We'll be verifying this the next two weeks.
You need to log in
before you can comment on or make changes to this bug.
Description
•