Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for team spaces in confluence #478

Closed
hurtstotouchfire opened this issue Sep 30, 2022 · 7 comments
Closed

Request for team spaces in confluence #478

hurtstotouchfire opened this issue Sep 30, 2022 · 7 comments
Assignees
Labels
github-request Request for change to access level or settings in the openedx GitHub organization.

Comments

@hurtstotouchfire
Copy link
Member

Firm Name

2U

Urgency

medium

Problem/Request

We would like to be able to move pages with technical context and documentation related to services we maintain to the public wiki. Right now this content is in the 2U private wiki.

Reasoning

This is rough content that doesn't quite fit into RTD or ADRs, it bridges repos, and it is frequently updated. Having a wiki space we are responsible for would enable us to make this information public.

@hurtstotouchfire hurtstotouchfire added the github-request Request for change to access level or settings in the openedx GitHub organization. label Sep 30, 2022
@openedx-workflow-automation
Copy link

Thank you for your report! @openedx/tcril-oncall will take a look as soon as they can.

@feanil
Copy link
Contributor

feanil commented Sep 30, 2022

@hurtstotouchfire can you elaborate more on what would be in team spaces that you would not put in project spaces?

@feanil feanil self-assigned this Sep 30, 2022
@feanil
Copy link
Contributor

feanil commented Sep 30, 2022

I'm trying to understand what would go in these pages if there are already product/project spaces.

@feanil
Copy link
Contributor

feanil commented Oct 3, 2022

@nedbat responding to #476 (comment)

@feanil I'm not sure we're all using the word "space" in the same way. I meant the Confluence space concept: an area of the wiki that can have different permissions than other spaces. 2U people could be the admins of the space, and then it could be subdivided into team pages and subtrees. Spaces are what provide the "XYZ" slug in URLs like https://openedx.atlassian.net/wiki/spaces/XYZ/pages/123456. I wasn't sure if we want to have a separate space for each team, or if that would be too many spaces.

I'm ok with whatever structure we settle on. The goal is to have a place for teams to be public and transparent.

I'm concerned about providing confluence concept of spaces for a couple of reasons:

  • I'm not sure what the legal implications are of doing so specifically with 2U so I'd have to check with legal on that.
  • Team spaces seem like an easy way to provide people with a dumping ground and not actually have the content be organized in a way that would be useful to the community.
    • Project spaces seem reasonable as it provides visibility on a specific thing and lends itself to some reasonable organization.
  • We already have spaces with the correct community permissions setup, and I don't see any reason to add more spaces with different permissions yet.
  • I'm not sure of the value of org specific spaces where people from the org are admins.

Ask: Can you elaborate more on the kind of content that would go here? If we have a place where project related content is kept, what would go here that would be useful for the community to be able to see?

@hurtstotouchfire
Copy link
Member Author

I think you're right about the dumping ground concern, but with the content viewable by anyone, we could at least have accountability. Right now we just have Ned asking about particular pages that are appearing in the private 2U wiki but there isn't an obvious place for them in the current public hierarchy, and taking on creating a place for them or organizing the public spaces is generally out of scope in the context of these individual pages being created.

I don't think we need org spaces or even that these need to be separate Spaces in the confluence sense. I think we could have a Maintainers space or the like, and have each maintainers team maintain a parent page in there which has some basic info about How We Work or how to contact us, and other that may be some working docs that don't yet have a home in the public hierarchy but might land one day in architecture or projects or something.

I think a synchronous conversation would be easier for this, but you can see a lot of examples in the archival copy of the Aperture space in the wiki. I'm trying to split this content into things that should be public and things that are specific to our internal team workings, and the latter is a minority of the pages. If someone wants to talk me through where these should all live in the current public hierarchy that might help.

I think the unescapable problem though is that we need to overhaul the public wiki hierarchy and do a bunch of clean up and I don't think that is a tCRIL priority right now. Even if I had places to put all the components of our team wiki I'd be afraid of losing track of them and never updating them because the SNR is so bad in Confluence. I need to have an index, at a minimum, of what my team is responsible for updating.

@nedbat
Copy link
Contributor

nedbat commented Oct 11, 2022

I've refactored the Community space a bit to add an Organizations page, with initial children tCRIL and 2U. Teams can be children of the organization pages.

@feanil
Copy link
Contributor

feanil commented Nov 28, 2022

It seems like Ned's changes have been sufficient so closing this. Feel free to open a new ticket and reference this one if you need more help.

@feanil feanil closed this as completed Nov 28, 2022
Repository owner moved this from To Do - Backlog to Done in Axim Engineering Tasks Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
github-request Request for change to access level or settings in the openedx GitHub organization.
Projects
Archived in project
Development

No branches or pull requests

3 participants