asyncapi / asyncapi/website

Proposal: regular Triage/Planning meetings and dedicated github project boards

Open
#4,717 22 comments 4 reactions 0 assignees View on GitHub
stale
Dominant language
TypeScript
Stars
716
Forks
1.2k
Avg merge
1d 12h
Merged PRs (30d)
35

Description

Hey folks,
I’d like to propose a few ideas to improve the maintainability and efficiency of this project.

#

### Regular Triage / Planning Meetings

Frequency: Once or twice a month

The concept of these meetings would be similar to what @derberg used to run for the generator and spec repo, and what @thulieblack does for the conference repo.

The broader agenda will be:

1. Discuss any issues and talk about what things we are currently working on on the website, and what areas need attention. Maybe if we need to discuss/implement anything, we can talk about it there and create the relevant issue there itself if needed. It will be easier and quicker since we’ll have `more hands (from maintainers side)` there on the call.

2. The second part would be `triaging`. We have so many issues open at the moment, so with more hands in the meeting, it will be really quick to `triage`, as sometimes we need another opinion and conversations over chat take longer compared to having the same discussion in a meeting. We can quickly triage the bugs/issues and maybe plan things for the website better.

#
### Two Separate GitHub Project Boards

`I’d like to propose maintaining two GitHub project boards:
`
- `Maintainers’ Board`
Inspired by the generator repo’s `Maintainer’s Work` board.
This board would track issues that maintainers are responsible for.

- `Contributors’ Board`
The idea is that whatever tickets/issues we have triaged or discussed in the above mentioned meeting will be marked as `triaged` by adding a `triaged` label and moved to that board. We are adding the label to segregate the issues and to easily identify which ones have not been discussed. `We will then use the contributors’ board to track the issues ourselves (maintainers). For now, there will not be any changes in the flow for contributors. It is just for maintainers to track and manage the issues that contributors are working on.`

For this `Contributors’ Board` part, yes, it is a rough plan and will be more of an experiment. Let’s see if it turns out to be effective. Please feel free to share your thoughts and input.

#
### Todo:
Can you guys please share feasible dates and times when you are available for the triage/planning meeting? I am thinking of having one this month, but I guess we might have limited availability due to year-end vacations. However, if we do have availability, we can try to have one this month; otherwise, we will start from next year

Please let me know your views: @derberg @akshatnema @anshgoyalevil @sambhavgupta0705 @Mayaleeeee @thulieblack @TRohit20 @bandantonio @devilkiller-ag @vishvamsinh28 @CBID2

Contributor guide

Open the contributing guide

Research direction

Start by reviewing this proposal and the repository’s current issue-triage and GitHub project-board practices; no implementation files or tests are identified. Done would require agreement on the meeting cadence, board structure, triage labels, and maintainer workflow before any configuration changes are made.

Written by the indexing model from the issue text.

Assessment

Tech stack
github
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.