Proposal: Reintroducing an Active Triage Team for Better Contributor Support (Code & Docs)

[Honyii]

Hello everyone, I wanted to open this issue to discuss a challenge that’s increasingly affecting our contributor experience. We’ve had several new contributors join the community recently, and many are eager to help. However, I’ve noticed recurring feedback that:

• Issues are not being assigned after contributors express interest, and
• Pull requests often remain unreviewed for weeks or months without communication or next steps.

While we previously discussed launching a mentorship program, I think the more urgent need right now is to re-establish an active triage team, at least 1–2 members dedicated to triaging issues, managing assignments, and keeping contributor communication flowing.

The previous triage members have done a great job but are currently busy with other commitments, leaving this gap unfilled.

Proposal

Let’s open a Triage Team Application within the community, with clear participation criteria such as:

• Being an active member of the community for at least 6 months.
• Having contributed meaningfully (PRs, issue discussions, or documentation).
• Demonstrating good communication and collaboration skills

Interested community members could apply in one of two ways:

• By creating an issue in the community repo explaining why they’d be a good fit (and optionally attaching their CV or contribution summary), or
• Via a simple Google Form — I’m happy to set this up if preferred.

After reviewing applications, we could host a short interview phase with selected candidates (one round, led by the TSC team) and confirm the new triage members.

Goal

To ensure contributors — especially new ones — have a smooth, engaging, and responsive experience when they try to participate.

What do you think?
Would love to hear your thoughts or suggestions on how to move forward with this.

[jviotti]

Issues are not being assigned after contributors express interest

On this point in particular, note that it is usually an anti-pattern to do so in open source projects. In most cases it is deliberate. In open-source, it is often referred to as "cookie licking" (read more about it here: https://www.redhat.com/en/blog/dont-lick-cookie)

Pull requests often remain unreviewed for weeks or months without communication or next steps.

That is indeed a problem. I wonder if it is because of lack of ownership (i.e. I don't think I have enough web skills to properly review a website JavaScript PR) or because people don't get the notifications / reminders.

Happy to try the triaging approach to see if it solves the latter.

[jdesrosiers]

This is definitely a huge problem right now.

I wonder if it is because of lack of ownership [...] or because people don't get the notifications / reminders.

It's definitely lack of ownership that's the problem. We have no one maintaining the website right now. It was mostly Benja since the new website was introduced, but he doesn't have time anymore.

Reviving the triage team isn't going to help until at least one person takes ownership of the website. I don't think any of the TSC is interested, qualified, and able to do that right now, so we need to be looking to the broader community to find someone who wants to do it. Once we have a maintainer, then reviving the triage team to help the maintainer out would make sense.

[jviotti]

Is it only the website that has this problem? Or do we have the same in other parts of the org regarding contributions? What is the distribution?

In any case, just talking about the website, my personal opinion (take it with a grain of salt) is that the fact that we do it with React and JavaScript and all of that adds a lot to the maintenance burden. I think it would be easier to get it done and even more robust and stable with less maintenance need if it was just plain static HTML on i.e. Hugo with maybe some sparkles of JS only when needed.

But hard to fix that at this point anyway.

[jdesrosiers]

Is it only the website that has this problem? Or do we have the same in other parts of the org regarding contributions? What is the distribution?

Good question. I did a little audit of repos we own and who I've observed being active in those spaces lately. Other than the website, the landscape site needs regular maintenance to at least remove inactive sponsors. I don't think anyone's doing that. @Honyii does that fall under your responsibilities? Also, the community repo needs regular maintenance. For example, I'm sure most of our ambassadors aren't active anymore. Finally, I think @JeelRajodiya
is the sole active maintainer for the tour.

There are several other repos that aren't active and don't have maintainers, but they aren't critical and can be ignored for now.

In any case, just talking about the website, my personal opinion (take it with a grain of salt) is that the fact that we do it with React and JavaScript and all of that adds a lot to the maintenance burden.

Agreed 💯. That's a big reason I haven't been interested in being involved with the website. Like you said, there isn't much we can do about it now.

[Honyii]

@jdesrosiers I can take a look at this and do some cleanup once I know who the active contributors are, maybe @Relequestual can guide me on how to get this info.

the landscape site needs regular maintenance to at least remove inactive sponsors. I don't think anyone's doing that. @Honyii does that fall under your responsibilities?

We also had a PR from last year about updating the contributing guidelines here

Also thank you for your comment @jviotti and @jdesrosiers , however in the meantime where could we direct new contributors because GSoC 2026 is coming up and we are already seeing new intake of people joining the community - directing them to the repos we have now seems to be not working cos no much maintainability.

My initial idea was having someone as a maintainer (I do not think I clarified in the description) and we use the $350 grant for this (if possible)- since I am not sure any TSC member is available to take up this. I've also had questions about the documentation side too, so also having a maintainer for this too if possible.

Another question is that, I know some toolings / implementers could benefit from these contributors- any idea on how we can do this under the JSON Schema umbrella (and if this is allowed?)

Basically the plan is, we are seeing new contributors, however directing them to the existing guidelines does nothing cos the repo aren't active - how could we solve this.

[jdesrosiers]

Another question is that, I know some toolings / implementers could benefit from these contributors- any idea on how we can do this under the JSON Schema umbrella (and if this is allowed?)

Yes! It's not only allowed, it's highly encouraged. I'd send them to the tooling page and tell them to pick one they like and start learning about it and contributing.

[benjagm]

Hi everyone. I think is important to have a group of people empowered to triage a maintain org repos. We had that in the roadmap and we even piloted a small group but the layoff affected that effort.

In addition, We don't have a contributor ladder in the project and this group can help a lot to reduce the gap between the TSC and the regular community.

Definitely I vote yes. What I am not sure if monetary reward is the best solution at first.

GSoC : we have more contributions probably because GSoC is comming. Are we planning to participate again? If not we should communicate it and that would reduce these small contributions that will grow in the upcoming weeks.

[Honyii]

@benjagm personally participating in GSoC again next year will be good for the org and we can use the same implementers strategy- it was really beneficial for implementers.

Are we planning to participate again?

Thanks @jdesrosiers, @jviotti , @benjagm for your comments and insights - now I know how to move forward, basically updating the welcome message to include navigating to toolings page and contributing to any project that speaks to them and finally open a maintainers form (with eligibility criteria) for the org repos.

[benjagm]

and finally open a maintainers form (with eligibility criteria) for the org repos.

Excluding the spec repo which is maintained only by spec authors.