AsyncAPI Initiative
Replies: 6 comments 18 replies
-
|
@fmvilas had a question with this about how will the working groups be decided? Like
|
Beta Was this translation helpful? Give feedback.
-
|
That's a good question. I guess anyone can create a working group. We should probably set that the minimum amount of people needed to create a Working Group should be something around 3. Happy to discuss any other ideas. I would not set any limit on the number of groups that can exist. I don't see a need for this but happy to listen to reasons, of course. |
Beta Was this translation helpful? Give feedback.
-
|
Updated the description with:
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree with the point of getting approval from the TSC for creating a new group. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, agree with this point. Otherwise we would be inundated with endless groups. |
Beta Was this translation helpful? Give feedback.
-
I had a question @fmvilas : |
Beta Was this translation helpful? Give feedback.
-
I think decisions should be taken by consensus. And if people don't agree on something, then they can raise the concern to the TSC. This is how we do it with code owners too. So far, we never needed that though.
You mean to have a working group that's focused on onboarding contributors? If that's the case, I'll have a surprise for you 😄
I think Working Groups should be beyond a repo. I mean, they're probably related to multiple repos. Therefore, having maintainers from these repos is helpful but not strictly necessary. The group can always reach to the maintainers of the repos involved to seek pre-approval from them. Or at least interest. |
Beta Was this translation helpful? Give feedback.
-
Regarding this it can be stored in JSON or YAML and automation can be added to convert to other formats and push to website. Maybe sth similar to the Maintainers one. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's what I was thinking too. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea, we should formulate the process so it is easier to kick of a working group.
is it necessary? I personally prefer more flexible approach to not enforce any specific project management tool. We should copy best practices from others: simple markdown with list of participants, most important links on how to connect and where group meets, the goal of the WG. We can keep it all in YAML file and render easily on the website as mentioned by @Shurtu-gal - all can be there without GH Projects
can you explain what it means? I understand that we need a short and focused group of people that run working group, with chair and stuff like that - people that are responsible for the WG - so yeah - lets assume up to 5ppl. But |
Beta Was this translation helpful? Give feedback.
-
|
Yep, at this point I think we're all aligned 👍 |
Beta Was this translation helpful? Give feedback.
-
|
yeah, YAML is not a hill I wanna day on. Can be markdown. YAML is better but that is just my opinion and actually human readable - at least that is what we advertise about asyncapi documents written in YAML 😆 We can also have a mechanism that reads markdown documents on website. Just hander will be to keep consistency and same structure that you could much easily enforce with YAML. Anyway, technical details. and last comment about contributors: definitely we should remember that like in case of repo work, we should always make sure we recognize every single contribution and who lead to the success of the work. |
Beta Was this translation helpful? Give feedback.
-
We could additionally keep a section on each WG page with a list of contributors/members section managed by the |
Beta Was this translation helpful? Give feedback.
-
|
Made some changes. Let me know if y'all agree now. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it's great now. |
Beta Was this translation helpful? Give feedback.
-
Maybe we can use GitHub Teams to create |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I like the idea 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Alright, so it's been 3 weeks and all positive votes so far so I guess we have working groups 🎉 I'm closing this discussion and moving the conversation to this PR: #1075. Thanks everyone for voting 🙌 |
Beta Was this translation helpful? Give feedback.
-
TL;DR: I want to regulate the use/existence of Working Groups official in the AsyncAPI Initiative.
Abstract
As our community grows, it's natural to see more and more people with specific interests: a specific programming language, a specific framework, Design, Documentation, etc. Even though many of these people join our community to participate in some groups, it's fair to say that these groups are "virtual", meaning they're not recognized in the charter and there are no specific rules around them. This was fine but I think we can make the most out of these working groups if we give them the importance they deserve, recognize their role, and set a bunch of governance rules to give them visibility and encourage consistency.
Important
The following is my proposal for what and how a working group should look like. It's not set in stone so happy to get feedback!
Definition of a working group
A working group is a group of people in our community who share a common interest beyond GitHub repositories.
A working group must have, at least, one of its members appointed as its chairperson.
Anyone can create a working group. The only prerequisites are to have at least 3 founding members and the approval of the TSC (Technical Steering Committee).
A working group should have its own set of goals or objectives. This helps everyone in the working group to stay aligned. The goals must be public and easily accessible by anyone on the internet.
It's recommended that a working group has an associated GitHub Projects project (or any other project management tool) where the group outlines their roadmap. It's up to the Working Group to decide the structure of the project. E.g., Kanban, Shape Up, TO-DO list, etc.
The name of the group, its members, the goals, and any other relevant information must be listed in the WORKING_GROUPS.yaml file in the
communityrepository.A working group has no decision power over the roadmap of the projects they may impact. It's up to the maintainers (code owners) of the repositories involved to approve or reject the resulting pull requests. Therefore, it's highly recommended to either have maintainers of the impacted projects in the working group or make sure everyone is in agreement before deciding about the roadmap of the different repositories/projects.
Working groups should be listed in the AsyncAPI website (asyncapi.com and asyncapi.org), along with their description, goals, members, an anything the working group wants to include.
Additional benefits
@asyncapi/tsc_members I need y'all to chime in. Please react to this with 👍 if you agree, 👎 if you disagree or 👀 if you don't want to vote but want to signal that you're aware and have read this. And of course, we welcome everyone to leave feedback for potential changes to the above. Cheers!
Beta Was this translation helpful? Give feedback.
All reactions