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

docs: add info about working groups #1075

Merged
merged 9 commits into from
Feb 27, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions WORKING_GROUPS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
### 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 clearly defined goals that are easily accessible to everyone on the internet, as this helps maintain alignment within the group.

It is recommended that the Working Group has an associated project management tool like [GitHub Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/creating-projects/creating-a-project) (or any other project management tool) to outline 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 group's name, members, goals, and other relevant information must be added to the `WORKING_GROUPS.yaml` file in the `community` repository.

A Working Group has no authority or power over the roadmap of the projects they may impact. It's up to the repositories' maintainers (code owners) to approve or reject the pull requests. Therefore, it's advisable to either have maintainers of the impacted projects in the Working Group or ensure everyone agrees on the roadmap of the different repositories/projects.

Working Groups should be listed on the [AsyncAPI website](https://www.asyncapi.com), along with their description, goals, members, and anything the Working Group wants to include.
14 changes: 14 additions & 0 deletions WORKING_GROUPS.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# This file contains the list of the currently active working groups.
#
# To learn more about working groups, read the WORKING_GROUPS.md file.

working_groups:
# - name: Required. The name of the working group.
# description: Required. Describe what this working group is about.
# chairperson: Required. GitHub handle of the chairperson. Example: @Barbanio.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if there are 2 or more chairpersons? better to have it as list imho, like in case of members

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmvilas fyi, yeah, it was merged before I had a chance to look into it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies. Just realized about your comments right now. Will open a separate PR.

# members: # Required to have at least 2 members who are not the same as the chairperson.
# - @fmvilas # GitHub handle of the member.
# slack_channel: # Required. The name of the Slack channel in the AsyncAPI workspace. Example: community_growth_wg
# okrs_url: https://example.com/xyz # Required. Link to a GitHub project, issue, or any other tool where the Working Group explains their objectives.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this should be required. As per the rules described in the Markdown file, it's required but I'm happy to change it if you think otherwise.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GitHub teams can be mentioned also as suggested by @Souvikns for better transparency and easy tagging.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reminding me. Also added Slack channel 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's no single sentence about ORKs in WORKING_GROUPS.md - so the name of property can be pretty confusing. And why required? I could also add ORKs as a bullet list here in YAML to get it rendered in website. Maybe just call it goals and define it as a field where you can write goals or provide link?

and I immediately ask what is the difference with roadmap_url - why separate link?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmvilas fyi, yeah, it was merged before I had a chance to look into it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies. Just realized about your comments right now. Will open a separate PR.

Copy link
Member Author

@fmvilas fmvilas Mar 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just created a PR: #1138. Regarding differences between objectives and roadmap, have a look at DX working group details. Long story short, objectives are for setting direction (the why), roadmap is exactly the issues/tasks (the what and how) you're going to be addressing in the foreseeable future (in their case 6 weeks).

# roadmap_url: https://example.com/xyz # Recommended. Link to a GitHub project, issue, or any other tool where the Working Group outlines their roadmap.
# github_team: # Recommended. The GitHub team handle to tag all the working group members at once. Example: @asyncapi/community_growth_wg.
Loading