Thanks @jblack7 for putting this together, and @dblessing and @peterhegman for your guidance 🙌

I think the hybrid solution is a reasonable compromise and gets us pretty close without impacting on project timelines or breaking SM/Dedicated.

I've asked @peterhegman to see if he has time to make some tweaks to @dblessing 's in-progress MR so we can demo the rough outline of this work for everyone else to see and understand as I appreciate this is complex with admin/settings/management etc.

I know this means we'll need some work from @jason_istakinganap – hopefully we can make this as painless as possible so we can iterate and get something out there ASAP.

Thanks all for – I appreciate it.

Thanks @chen-gitlab (and @abdwdd / @rutgerwessels for clarity).

Since we began this work, the plan has changed slightly for Organizations transfers, eg:

• We plan to run a lightweight/low-overhead initial transfer of TLGs => Orgs
• This transfer will be an atomic operation, eg. write a new Org and then update the TLG to belong to it
• This will not require read-only mode because it's instant and does not move any underlying data, so no customer operation could influence/modify the output (except, I guess, renaming/deleting their TLG at the moment of transfer...)
• Eventually, we'll deliver Isolated Organizations, which includes a "preview mode" the customer can enable against their org. Even then, no data moves around (can you confirm this, though, @dblessing ?) – we simply enforce some rules around query scoping
• Finally, the customer completes "severance" and is fully isolated. At this stage, we'll complete some data modifications, although @alexpooley suggested that this could be a gradual/async/background task(?). At this point, we may need TLG-level read-only mode, but we may be able to achieve the same thing at a higher level by placing the parent Organization in read-only mode

TL;DR – I suspect that we no longer need TLG-level read-only mode, as every TLG in scope for this will be part of an Organization by the time we require them to enter a maintenance state. Therefore, this work should solely focus on implementing an org-scoped read-only mode and this can cascade down to a TLG by definition.

(can anyone else confirm?)

Matt Andrews (08e236c4) at 17 Mar 13:45

Matt Andrews (e71e5c1c) at 17 Mar 13:45

... and 1 more commit

Why is this change being made?

This change updates a project assignment table for an engineering team. The old table had 5 projects with specific team member assignments, while the new table has 8 projects with updated names, links, and different team member assignments.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Update current projects in Tenant Scale > Organizations

---

Hi again @drew – I just wanted to confirm: are you happy that visual_review_bot is now migrated, and we can close this issue? It's the only one remaining in the parent epic.

Awesome! Thanks for doing this 👍🏻

Why is this change being made?

This change updates a project assignment table for an engineering team. The old table had 5 projects with specific team member assignments, while the new table has 8 projects with updated names, links, and different team member assignments.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Update current projects in Tenant Scale > Organizations

---

@tkuah sorry, late to this – thanks for doing it, looks good! (I know it's merged, just wanted to acknowledge 😅)

@rymai thanks for doing this!

There are the epics I currently report against for the Grand Review:

--

Groups & Projects epics

1. 🟢 ← Apr 10th State Management Iteration 4: Replace legacy state checks with new system
2. 🟢 ← Mar 13th Migrate Explore > Projects to Vue
   • Feature is fully rolled out! Only remaining work is post-launch cleanup.
3. ⚠️ ← Mar 13th Migrate Explore > Groups to vue_shared/components/groups_list
   • We have a small piece of work left here to fix a pagination bug. The work is in review and should complete soon, however.
4. ✅ ← Mar 13th Make project archival features compatible with group archival
   • The feature is enabled on production. Remaining work is scheduled for follow-up tasks, eg. additional enhancements and downstream/external changes to support the new state. I'll stop reporting on this epic next week and we can move to following up the later work as it's prioritised.
5. 🟢 ← April 10 Standardize deletion experience
   • This work is now back in progress after Rémy returned and we only have a single item left to complete.

Organizations epics

1. 🟢 ← Oct 31st Create an Organization Administration Area
   • Updated due date (for now) but this will change as we confirm the new Organizations timeline. We have a POC in review for an initial/MVP admin.
2. 🟢 ← Mar 13th Cohort A Transfer group to an Organization
   1. Work is complete minus blockers and post-launch cleanups.
3. 🟡 ← Apr 10th Enforce minimal Organization data isolation in Rails
   • Updated due date and incremental rollout plan is now in action thanks to Kamil's support. Initial MR will be merged this week.

--

It may be worth removing Teams for now because it's not in progress/blocked, and possibly splitting the list into Groups & Projects and Organizations for clarity?

@chen-gitlab great update – thank you!

A quick note on timings though: gitlab-org#19841 (comment 3165675513)+s

@timmccarthy thanks for this! Just a note on reporting cadence:

• This bot pings everyone for updates on a Thursday
• On Friday, I write my summary of the whole team's statuses for the Grand Review
• On Monday, Nick combines all the GTS updates into a single status update
• On Tuesday, Infrastructure Platforms leadership record a video showing the Grand Review content for each team/stage.

... so I need you to write these updates when the bot pings!

It'll ask you again on Thursday this week so if nothing else changes between now and then, I'll use this post. But otherwise, try to write the updates on the same day otherwise you'll miss the update cycle.