Closed Bug 843254 Opened 12 years ago Closed 11 years ago

[research] no more pto for r1cky

Categories

(support.mozilla.org :: General, defect, P1)

defect

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.
Who's Ricky?
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
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.
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.
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
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
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.
I haven't been able to reproduce. Can you provide detailed steps?
Status: NEW → UNCONFIRMED
Ever confirmed: false
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
Q1 is in the past. Moving to the future.
Target Milestone: 2013Q1 → Future
Assignee: nobody → rrosario
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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
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.
Severity: normal → blocker
Hoping this goes unnoticed during the great triage of 2014.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
I saw that!
Resolution: INVALID → INCOMPLETE
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.