Bug #14511
Share the Help Desk shift schedule with Foundations Team members
0%
Description
As decided at 2017 summit, we should make public our shift schedule so other teams can know who to talk to.
Subtasks
History
#1 Updated by mercedes508 2017-09-11 17:53:15
- Assignee changed from mercedes508 to emmapeel
Decided during september help desk meeting to share ou shift schedule (and some other useful things) was better with devs only, so we’d like to have a public section in our git, accessible for others than help-desk members.
#2 Updated by intrigeri 2018-01-12 12:14:27
- Subject changed from Make public help desk shift schedule to Share the Help Desk shift schedule with Foundations Team members
- Target version set to Tails_3.5
mercedes508 wrote:
> Decided during september help desk meeting to share ou shift schedule (and some other useful things) was better with devs only,
OK. I can live with that tradeoff if the additional requirements don’t imply it takes ages to become real (compared to the simpler option that was decided earlier at the summit, which I could implement myself right now and be done with it). Four months have passed already, perhaps we can we aim to get this done within 2 months?
> so we’d like to have a public section in our git, accessible for others than help-desk members.
I don’t know if/how we can do that.
I think the simplest way to implement what you decided is to create a new Git repo, where you can put the shifts schedule and whatever other info you want to share with us. I’ve created a new private repo for this:
tails@git-tails.immerda.ch:frontdesk-shared.git
. For now only help desk members and Foundations Team people have access to it.
Please set this up in the way you prefer: I guess cleartext is good enough, but if you really want you can use git-remote-gcrypt. And then move at least your shifts schedule there :)
#3 Updated by emmapeel 2018-01-12 21:07:05
- Status changed from Confirmed to Fix committed
- Assignee changed from emmapeel to intrigeri
- QA Check set to Ready for QA
Ok, I have updated the repo with the next steps. Now we have to remember to update this repo when we change the other.
Maybe we could just ditch the other file and start using this schedule.
#4 Updated by intrigeri 2018-01-15 10:59:46
- Status changed from Fix committed to In Progress
- Assignee changed from intrigeri to emmapeel
- QA Check changed from Ready for QA to Dev Needed
> Ok, I have updated the repo with the next steps.
Thanks a lot! I could clone it and I confirm the data I need is in there.
> Now we have to remember to update this repo when we change the other.
I’d rather not rely on that. Duplicated data sets that are supposed to be manually kept in sync’ inevitably end up desynchronized sooner or later, which is precisely the reason why when we discussed this at the summit (which resulted in this very ticket being created), I’ve insisted to have access to the canonical version of this data. So:
> Maybe we could just ditch the other file and start using this schedule.
Yes, let’s please do that (I would do it myself if I could but I cannot). The old file can e.g. have its content replaced by a pointer to the new location :)
#5 Updated by anonym 2018-01-23 19:52:50
- Target version changed from Tails_3.5 to Tails_3.6
#6 Updated by emmapeel 2018-02-27 14:20:54
- Status changed from In Progress to Resolved
- Assignee changed from emmapeel to intrigeri
- QA Check changed from Dev Needed to Ready for QA
OK, during our last frontdesk internal meeting we have decided we don’t want to share the rest of the information that we have on our shared calendar, like individual clocking times and internal work dates.
So we are still going to keep a calendar of our own, but we will do the shift schedule on the shared one.
In the meantime, this shared repo has included another file so is growing to be a nice resource!
#7 Updated by intrigeri 2018-02-27 14:37:00
- Assignee deleted (
intrigeri) - QA Check deleted (
Ready for QA)
I can’t review the current state of things in your Git repo (I don’t have access to it) but I trust you that the data duplication concern I’ve raised was solved. Thanks!