chore: Remove Sec Architectural Council in favor of #sec_staff_plus
Why is this change being made?
The Architecture Council was initially formed as a means to drive collaboration and consensus across the section on widespread initiatives.
My minimal suggestion is to refocus section-wide initiatives as a collaboration opportunity and open it up to all current and aspiring Staff+ via our newer #sec_staff_plus
channel.
The current template feels more like a mandate and while we could theoretically end up with some drop-off in participation (in the rare event “Gondor calls for aid”), I’m willing to accept that until it becomes a problem.
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 Directly Responsible Individual/s (DRI) - If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
Maintained by
section on the page being edited - If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
- The when to get approval handbook section explains the workflow in more detail
- If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
-
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
- chore: Remove sec Architectural Council
The council has outlived its usefulness and is no longer relevant
Merge request reports
Activity
added HandbookContent label
assigned to @theoretick
requested review from @twoodham
- Resolved by Lucas Charles
- Resolved by Huzaifa Iftikhar
added 1 commit
- d09d4462 - chore: Fix sec headings, remove councils section
Using combined codequality.json
️ Pipeline Failure - Linting ErrorsOne of the linters has reported errors and as a result the pipeline has failed. Once the pipeline completes, you'll find the code quality report above which can link you to where the error is in your code. Additionally, below you'll find a table of the errors. The table has links to the lint rules so you can find more information on how to fix the issue(s).
Rule File Line Error MD012 content/handbook/engineering/development/sec/_index.md 444 Multiple consecutive blank lines [Expected: 1; Actual: 2] If you need more help please reach out on Slack in #mr-buddies.
- Resolved by Lucas Charles
added 49 commits
-
2bc4befe...9d6fe696 - 46 commits from branch
main
- ad5ee291 - chore: Remove sec Architectural Council
- 69007d39 - chore: Fix sec headings, remove councils section
- a2b945a3 - Apply 1 suggestion(s) to 1 file(s)
Toggle commit list-
2bc4befe...9d6fe696 - 46 commits from branch
added 81 commits
-
a2b945a3...5732ac9d - 80 commits from branch
main
- 11be0a9d - Merge branch 'main' into 'theoretick-main-patch-65438'
-
a2b945a3...5732ac9d - 80 commits from branch
@theoretick - FYI I just resolved a merge conflict, and I think the resolution is in keeping with spirit of this MR. I'm going to merge this as soon as the pipeline passes unless you want to put up a
In situations where most impacted group is not clear, Senior IC leadership via #sec_staff_plus will be engaged to help discern which group that might be.
The council was more inclusive than a channel for Staff+ as team members could in theory be rotated on/off, and given opportunities to represent their group in discussions. Not all teams/groups have a Staff+ engineer.
@pcalder thank you for that callout, it's a good perspective that got missed. I would broadly say any individual is welcome to propose opportunities across the stage and hope that's understood. One concern with the previous council was also inclusivity in that it did not seem apparent that individuals outside of its membership were able to propose significant changes. The quorum requirements were both too rigid and too ill-defined, so I'm still happy to remove the previous incarnation but we could take additional measures to make its replacement more clear.
I proposed
#sec_staff_plus
to more closely align with other sections like#ops_staff_plus
. If we do not think that's a fitting alternative for the reason you outlined (or we find the update toAll people and ideas welcome! (not limited to Staff+)
unsufficient) we could consider renaming the channel to something like#sec_technical_leadership
, or perhaps#sec_ic_leadership
to avoid overlap with#(secure|govern)_development_people_leaders
.Naming is hard and I welcome some iteration until we get it right.
I will say that - while I joined
#sec_staff_plus
because I saw the early encouragement that it was not just for Staff+ (and might have joined even had I not seen that) - the contradiction between the channel name "Sec Staff+" and the description "not limited to Staff+" does feel odd. Is it for Staff+, or not? If not, why is it named that? The uncertainty there might put some people off (especially since that part of the description is "below the fold", i.e. not visible until you expand the channel description).That being said, I'm not sure there is a (succinct) name that perfectly encapsulates "technical leadership, which anyone can be a part of but is more of a responsibility the higher your level and is particularly expected from Staff+", which I think is the intended purpose. It's certainly not the first time I have seen engineering orgs struggle with this dichotomy, and I've not yet seen a great answer
I like your suggestion
#sec_ic_leadership
Lucas, this feels more inclusive. From a career development perspective we consider IC leadership as a Staff level competency, but of course team members are encouraged to demonstrate leadership as they consider, or work towards, this level.Edited by Phil Calder@theoretick @pcalder Since the intent is to have discussions across multiple groups in the section and we want everyone to be able to contribute, maybe we should:
- Call the channel
#sec-section-engineering
- Have these discussions in the
#sec-section
channel
I notice that
#sec_staff_plus
doesn't see much use (and neither did#s_sec-architectural-council
) so my preference would be for option 2 as I don't see much reason for a dedicated channel.Edited by Brian Williams- Call the channel
Have these discussions in the
#sec-section
channel I'm always happy to have fewer channels and personally think an occasional threaded conversation is a small enough addition that it balances awareness with additional noise. Unless there are objections I'm in favor of dropping the channels altogetherSee follow-up MR !7143 (diffs)
maybe we should:
- Call the channel
#sec-section-engineering
- Have these discussions in the
#sec-section
channel
#sec-section
works (thanks for follow up MR Lucas) but might get a bit noisy.If we want to have a single engineering channel, how about we rename
#sec-eng-requests-for-help
to#sec-section-engineering
as the channel for engineers in Sec to collaborate on engineering topics? WDYT @theoretick, @bwill, @twoodham ?- Call the channel
If we want to have a single engineering channel
I don't believe we do. We have had only 1 post in
#s_sec-architecture-council
not related to this topic and none in#sec_staff_plus
in the last 90 days.but might get a bit noisy.
Emphasizing "might", creating a dedicated channel feels like premature optimization. Happy to reconsider once we see a need but the reality is that we do not have one at present.
Edited by Lucas Charles
mentioned in commit e39c70dd
mentioned in issue gitlab-org/govern/compliance/general#235
mentioned in merge request !7143 (merged)
mentioned in merge request gitlab-org/gitlab!171215 (merged)
@theoretick, I came across your MR about retiring the Sec Architectural Council and was trying to understand where these discussions happen now. I noticed it initially mentioned moving to
#sec_staff_plus
, but that channel doesn't seem to exist anymore. Where would you recommend engineers join on Slack if they want to participate in section-wide technical discussions?/cc @thiagocsf
@philipcunningham, I see a lot of similar discussions happening in
sec-eng-requests-for-help
(internal).Where would you recommend engineers join on Slack if they want to participate in section-wide technical discussions?
I don't think we have a single location anymore because we didn't use it and had scaled beyond being able to have such discussions effectively across the section.
There's no real equivalent of anymore but the self-service channels like
#sec-eng-requests-for-help
are certainly available. SRM has a#s_srm_security_eng
for engineering-focused discussions which AST might benefit from mirroring, but ultimately these are all fairly passive ways where volunteers can choose to participate. Those can be helpful for asking for help but maybe less so if you want to participate or exercise your coaching skillset.The Architecture Council has an expectation of participation which we decided to not continue with but it's also somewhat of a loss. Hopefully those slack channels can help with what you're seeking!