Internal Tooling at Tor Project
Are the tools we are using working for us?
Facilitators: gaba, pili, anarcat
Time: 1 hour
- Review existing tooling vs team requirements
- Move forward discussions on issues that we have been already discussing:
- email issues
- ticketing system migration to gitlab
- guest accounts
Materials and Equipment Needed
- sticky notes
- list of what needs to happen before migrating to Gitlab
- list of what needs to happen before migrating to Nextcloud
- Migration into gitlab dip discussion
- Document on options for email
Topics that we need to look at
Review existing needs/requirements
- Issue tracking:
- Project Management
- gitlab boards
- Collaborative document editing
- google docs
- Meeting pads/notes
- Meeting Scheduling
- Shared calendars
- Video/Audio Conference
- Which categories of tools should be standarized and which tools can be used ad-hoc?
- Review existing toos at Tor
- google docs
- Toolds under review
- Decision making process
- Migration process
Services currently running
git.tpo - kind of maintained
rt - currently unmaintained, steph uses that for press queries, donation queries; big spam problem; steph is looking at it new messages relgularly; unmaintained
storm - currently unmaintained
blog is fine but blog template is usually breaking with drupal update; Converting to lektor? If so, we would not have comments. Maybe using Discourse or something else?
Potentially new services
- opening a document in onlyoffice takes longer than storm
- asking people for feedback in august to help with a decision migration plan
- OnlyOffice issues:
- word count?
- tagging comments?
- Should we migrate svninternal/corporate svn? And if so, how?
- Uptime requirements for Sue?
- Concrete plan on what is going into Nxtclound and what not and how this should be exposed?
- having a unified platform for everything (calendar etc.) is pretty worthwhile taking into account what we have today
- Linus is asking nextclound testers in August for feedback to make a decision in September on how to move on
We should generally build a guide for secure, private, and public stuff organization-wide
- network-team: moving to Gitlab is okay, still accepting pull requests on Github
- anarcat is summarizing the anonymous/guest account session
- having Gitlab helps porting software to *bsds (Gitlab API is useful here)
- Trac queries and wikis?
- CI integration (Travis hooks, Appveyor etc.)? You are able to hook up runners from anywhere and scope them permisson-wise
- Dozens of other small Tor projects could be a good target first before dealing with the larger projects like tor and Tor Browser
- maintainership of Gitlab projects is more fine-grained/trickle down fashion than gitolite (who makes sure configuration is not rotting?)
- Do we have someone being able to scan for permission anomalies (yes, it could be some project admin)
- gitolite permissions should be able to get replicated in gitlab
- decentralized versions of access control does work better than centralized ones as the groups know better about themselves than a central entity
- all in all there are no real blockers for the gitlab transition
- we need to come up with a ticket migration plan
- maintenance cost
- running Gitlab ourselves is not cheaper than outsourcing it
- there will be a maintenance cost which is currently not clear
- push access only in one direction
- issue with providers like Google which is just not delivering emails from torproject.org
- anarcat summarizes the current state of the discussion