diff --git a/policy/tpa-rfc-66-gitlab-ultimate-program.md b/policy/tpa-rfc-66-gitlab-ultimate-program.md
index 7d62c98364c8036973002779ade7942ec9c4b5a1..32704d7ade66d18b8e3b560a3afbcd011162404f 100644
--- a/policy/tpa-rfc-66-gitlab-ultimate-program.md
+++ b/policy/tpa-rfc-66-gitlab-ultimate-program.md
@@ -39,9 +39,7 @@ good for tackling old tickets, requests and bugs.
 
 Still, there are limitations that we hope we can overcome with the
 features in the premium tier of Gitlab. This document explains how we
-are working on projects and software development (TODO still?) as well
-as trying to understand which new features Gitlab Ultimate has and how
-we can use them.
+are working on projects as well as trying to understand which new features Gitlab Ultimate has and how we can use them.
 
 It assumes familiarity of the [project life cycle][] at Tor.
 
@@ -93,15 +91,19 @@ request, and only GitLab administrators can manage server-side hooks.
 
 ### Custom Permissions
 
-**Definition**: In Gitlab we have roles with different
-permissions. When the user is added to the project or group they need
-to have a specific role assigned. 
+**Definition**: In Gitlab we have roles with different permissions. When the user is added to the project or group they need to have a specific role assigned. The role defines which actions they can take in that Gitlab project or group.
+
+Right now we have the following roles:
+- guest
+- reporter
+- developer
+- maintainer
+- owner
 
 In Gitlab Ultimate, we could create [custom roles][] to give specific
-users permissions different permissions than the ones in roles.
+permissions to users that are different from the default roles. 
 
-TODO: clarify what, exactly, we would do here. What is the problem
-we're trying to address?
+We do not have a specific use case for this feature at Tor right now.
 
 **How we are using them now**: In the top level group “tpo” we have
 people (e.g. @anarcat-admin, @micah and @gaba) with the owner role and
@@ -128,9 +130,7 @@ team and the assignments.
 
 (We used to do this only with pads and wiki pages before.)
 
-We may still need to have an overview of the roadmap with assignments.
-
-TODO: clarify: the overview would be in a spreadsheet?
+We may still need to have an overview (possible in a spreadsheet) of the roadmap with allocations to be able to understand capacity of each team.
 
 Epics can be used for roadmapping a specific projects. An epic is a
 “bucket of issues” for a specific deliverable. We will not have an
@@ -160,9 +160,7 @@ completed work for a milestone.
 
 **How we are using them now**: When we moved from Trac into Gitlab we
 started using milestones to track some projects. Then we realized that
-it was not working so well. TODO: why? I was relying mostly on boards
-with project labels and reviewing each objective of the project in a
-different way. Now we are using milestones to track releases as well
+it was not working so well as we may also need to use milestones for specific releases. Now we are using milestones to track releases as well
 for tracking specific features or goals on a project.
 
 **What problem we are solving**: We will be able to understand better