[tor-bugs] #31243 [Internal Services/Tor Sysadmin Team]: TPA-RFC-2: define how users get support, what's an emergency and what is supported

[Tor Bug Tracker & Wiki]

#31243: TPA-RFC-2: define how users get support, what's an emergency and what is
supported
-------------------------------------------------+-------------------------
 Reporter:  anarcat                              |          Owner:  anarcat
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Internal Services/Tor Sysadmin Team  |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tparfc                               |  Actual Points:
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by anarcat):

 >  I think the draft is actually good as a start. I just would like to add
 that as the sysadmin team is currently small and there might be specific
 situations where a code RED might require more time than expected and as a
 organization we need to do an effort in understanding that.

 That's what I tried to explain in the first part, with the "work times of
 available staff" bit. But maybe we could expand and include your sentence
 above to make that crystal clear. :) I've done just that now, see if it
 fixed it. :)

 >  Another observation I have is that we could add to this a procedure
 regarding when and if the sysadmin team decide to adopt a service.

 True! that would be a good procedure to have. But for now I'd like to
 focus on the "oncall" side of things...

 For the record, we discussed this last in stockholm and those are the
 relevant notes, I think:

     We end up with having to keep hosts and services running long after
 the initial people who wanted it left. We also run some things directly as
 torproject-admin. We should have some list of requirements for things we
 (and also others) run on our infra. This list would include that sw needs
 to have proper releases and installation instructions and procedures, a
 bug tracker, some means to contact upstream, and it needs to run in the
 lastest Debian stable (and when there is a new Debian stable, it needs to
 run on that within a month or three.) There needs to be some commitment of
 maintainership, not only by individuals but by the project/corp, meaning a
 promise of recurring money to keep this service working. It's never just
 about setting up. We really really want at least two people who know and
 maintain each service. Also, this policy should apply not only to incoming
 services, but it should apply to all the things we run and we should
 regularly evaluate whether services meet them.

 Extracted from
 https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Notes/SysadminTeamRoadmapping

 So maybe it's just a matter of spelling this out in bullet points and
 adding it to the support policy?

 > E.g. gitlab. If we shutdown tor git at some point that would be where
 all our code lives and that worries me a bit because I think that would
 become a complex first tier service.

 For the record, I consider gitlab to be a "service" under the "service
 admins" umbrella. I have explicitely pushed back on the idea of throwing
 TPA under that bus for now, and we will need to have a team managing
 gitlab if we want this thing to work at all. :)

 Of course, we have a tendency of falling back to TPA when things fail in
 the service admins team, but at least we should have that buffer for now,
 until we redefine those distinctions.

 > In this procedure we might take into account that if a team request a
 service they have to be also responsible for it. I.e. dedicating time and
 resources to maintain the service. Sometimes if the service is important
 for the organization we should require that at least a few people from the
 org step up and take that service as a collective responsibility.

 Absolutely. Before we close this ticket, let's make a service admission
 policy, based on your comments here and the Stockholm discussion...

 Do you want to draft something? You seem to have good ideas! :) Otherwise
 i can try to make a summary...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31243#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online