Teams are building blocks for our community and basic entities of belonging. That’s why it’s important to have a good implementation of the team concept.
Important to mention that some teams can imply some project/sub-project governance and some can be just bunches of people with similar interests. So this topic is general and not about governance.
Current situation with teams (aka working groups) in the project:
The working groups are living (many containing irrelevant info) in Wiki
Wiki pages just don’t look good in general. Having a list of general or project-wide teams on docs.ansible.com would look better, presentable, prestigious, official, mature, etc. See Fedora or Ubuntu teams page. UPDATE: we’ve decided to try forum groups for that. I created a common layout for admins to copy-paste when creating groups that group owner will fill up ourselves later
We can now see the whole list of WGs on docs.ansible.com only in Communication guide. I know it but if you Google you’ll fail to find anything besides this MD.
“Team” sounds IMO better than “Working Group”, more friendly and social, and less “doing hard work in free time” associated:)
There’s no official team page layout (see the proposal below). UPDATE: created in the Staff category.
What could in my opinion make things better:
Creating a list of teams on docs.ansible.com: layout similar to Fedora or Ubuntu’s LGTM: they both are split into categories most of which are based on certain types of work community members want to do, i.e.: UPDATE: we’re thinking of rendering teams on the new community site via discourse API
“Core” teams (we can call the category differently), which will include Steering Committee, Doc team, Release management team, etc.
Initiatives & Special Interest Teams: it shouldn’t probably contain teams bound to particular collections. It could contain general teams like, say just for instance, “Collection team” or “Execution Environment team”.
something else
Each team has its own page and it’ll use a standard team page layout we’ll develop. UPDATE: done
Your thoughts on the idea not focusing on the details much?
TODO
We’ve decided to try to implement teams in the forum; then we can render them on the community site via discourse API
Created the group layout template (in the Staff category)
I think you’re talking about a small number of specific high-importance teams, but I think we can widen the scope a bit.
I’m all for improving the documentation of our community structure in general. I’m not opposed to a list on Docs and a page for each team, but it adds a maintenance burden to the docs to keep it up-to-date. Naturally, this implies the list of teams should be small.
However, we also have many Working Groups, and I’d like to make that more visible to the wider community - as you say, the GitHub wiki isn’t the most discoverable thing. Naturally, I’m going to suggest using the Discourse Groups function here (I’m so predictable )
That (I think) is a lot of what you’re looking for, including a page of explanation, further links, membership list, and so on - and can be managed by the group itself, meaning low-to-no maintenance for us.
I do agree there is a place for a more prominent page of information, either in the docs or in the new website. I quite like that we could lean on the Discourse Groups API to retrieve a lot of group information - so perhaps a hand-crafted section for the high-profile Teams, and then an autogenerated list of Working Groups underneath might be quite nice?
I agree that more prominent pages with information (as @Andersson007 mentioned above + the meeting timing and platform of the working groups ) regarding different groups within the our ecosystem seems a good (rather a necessary idea) and for me the new website is the place for that.
In addition to the I would love to see a clear structure of the Governance Model of the overall ecosystem.
I’m not sure if those working groups / teams really exist. Maybe we should decide what’s really a working group / team and what isn’t.
For example, the VMware Working Group doesn’t really exist. The information in the wiki pages is outdated at best, sometimes even misleading. Personally, I would kill this “working group”.
Looking at some other WGs also makes me think what to do about them. For example, the Kubernetes WG seems to be just about the kubernetes.core collection. I don’t think this is worth a WG / team.
After playing a bit with groups, i have the following points in mind:
If we implement Teams as discourse groups only discourse admins can edit its description, add an avatar, etc. I found info that ownership gives a permission to invite people but i don’t see owners have other permissions.
If p. 1 is true + if only admins can create groups and edit them, it’d be a real issue (and a lot of work for admins).
If p. 1 and p. 2 are fair, should the Teams be implemented via a group + a post of type wiki? What do you think?
If p. 3 is OK, i think:
a) we should create a special category “Teams” or whatever to mark such posts. Every group will contain a reference to a corresponding “team’s page” post
b) if only members of associated group can edit, it’d be great
c) can we disable comments in such posts? It’s important I think. I don’t see this in topic settings.
(1) is not true, group owners can configure most things (certainly descriptions, access rules, flair, titles & and membership). You do need an admin to create a group, but that won’t be a frequent task, and the group can look after itself thereafter.
I assume that invalidates the rest of your points? You don’t need a wiki post & tag if groups can look after their own pages. However, I would say that the groups page isn’t the easiest to find. I could move it up into the top part of the sidebar (above More) if that would help?
Rendering things on the new website via the API is definitely worth looking at, I’ll add it to my todo. I should end up being quite similar to the Events page in operation, I hope.
I would also agree that this is a perfect time to review the existing groups. I do think many could go, and that would simplify the chat space as well. That’s probably a new topic though - we should do that after the official launch, we’ll want eyes on it before we close any groups down.
This is also an opportunity to review how we create new Working Groups / Teams. But let’s get the existing ones set up here first.
Mission: describe a team, it’s mission, goals briefly
Scope & Responsibilities: describe a team’s scope and responsibilities
Contributing: put links to contributor guidelines or describe briefly if possible
Who can join: describe how to become a member (Greg’s suggestion)
Communication: links to communication channels and their brief descriptions
Governance: describe how a team is governed, e.g based on meritocracy and consensus among participants.
Contacts: how the team leaders can be reached out to.
I suggest using this layout when creating other teams.
Questions:
Are you OK with using this layout as basis? If yes, I could create a wiki post for that to copy past things conveniently. It’ll serve as a sensible starting point and teams can change it if they want.
Should we add / remove / change anything in the layout?
That’s awesome, thanks @Andersson007! The only thing I would add is perhaps an explicit “who can join” section (or as part of Governance) - I had to go into the group settings to find out that you’d ticked “anyone can join”
+1 for documenting it. Wiki is fine[1] but I’d also be OK with a wiki post here somewhere too. It does relate to forum config, after all.
although I wonder about the future of GitHub wikis vs Docs & here - yet more fragmentation! ↩︎
@Andersson007 this is a great topic, and I think it’s a great opportunity to do some definitions. And although I agree we can work on this by itself, I feel this is part of the wider Governance topic as mentioned by @anwesha . So we might want to keep it in mind when doing/proposing changes.
I agree with most of what was mentioned above and like the idea of using the forum features to create and maintain those groups as proposed by @gwmngilfen , but I would like to add a few thoughts on the naming of groups. Naming is quite important and we should try to be clear in our intent. We usually see 3 types of “group” names in Open Source projects
We should start by defining those types of groups and how they apply to our structure, as those are the standard when looking at other projects. We could then move to Committees, Councils, and other higher function bodies we deem necessary.
If possible, we should try to stick to definitions that we know work on other projects and to keep it simple. Although it’s always good to customize to adapt to our own community, these terms seem to be quite wide and modifying their meaning means explaining to people coming or involved in other projects what’s the difference, which might not be a great experience.
From my non-native speaker perspective, I would prefer Teams because:
It sounds friendly, informal, and simple (compared to Special Interest Group or Working Group).
It sounds general implying a group of people acting together to reach a common goal and it doesn’t necessarily work related, e.g. it can be a amateur basketball team of people who play for joy, etc.
The goal of the suggested layout is to make teams/group pages more consistent and informative, and give team owners clues what to put in their teams descriptions. They can throw out some sections like Governance if they don’t need them.
I think the question how to call it is mostly about which notion to use in our docs. Ultimately, teams are free to call themselves as they want. For example, in Ubuntu I can see “Kernel Team”, “Bug Squad”, or “Papercuts Ninjas” and it’s imo absolutely OK.
I agree - I think we can make distinction between the word(s) we use in our docs and processes, and the label a group gives to themselves. I would agree with @Leo that there is a hierarchy to create terms for later (we already identified two levels of group at the beginning) but that’s a paperwork thing.
I’ve created the group layout template (in the Staff category). Admins are encouraged to use it when creating new groups updating along the way if needed.
We should probably check Ansible communication guide if it should also be updated (i’ll do it). We’ll at least put refs to the forum in there. I’ll also update our internal pages about WG creation.
Please put your thoughts on ^. If there’s support, I’ll start doing it ASAP
Clearly I’m ok with all of this in principle - this is all my faultidea anyway .
But just to clarify, is this just for new WGs in the future? We’re doing the official launch today, does it make sense to hold fire for another week or so? Do we need input from people who might not have a forum presence yet, particularly from existing Working Groups?
I’m + for updating the front of that repo to point here instead of the mailing lists though. There are doubtless more places we’ll need to update relating to that.
(Side note, if you want to ask questions, do make use of Polls )
I agree with @gwmngilfen, I think we should hold for a while, let people sign up and get used to the forums first. The change is needed, but it’s also one that involves a lot more maintainers and contributors (than just the community team), and it’ll be better to give everyone a chance to see this topic and maybe even provide some input.
I agree with @cybette and @gwmngilfen here. It would be ideal to give more time to the wider community to be familiar with the Forum and workings of it and then introducing different blocks on the top of it, along with the detailed and reasoned documentation. I would prefer 2 weeks time to introduce the proposals.
Also on a separate note what is the difference between SIG and WIG in respect to our community?
)
for updating the front of that repo to point here instead of the mailing lists though. There are doubtless more places we’ll need to update relating to that.
)