Help for specific SIGs that reached out (Ruby, Operator)

[svrnm]

What can we do in general?

What can we do for the specific SIGs?

• Operator needs more approvers: who's in to help them figure out a plan?
• Ruby needs more contributors in general: who's in to help them figure out a plan?

cc @open-telemetry/ruby-approvers @open-telemetry/operator-approvers

[svrnm]

Here is a first proposal, what we can do: we implement a program to promote SIGs via our social channels and let people know that they are looking for people to help. To turn this into a reproducable effort, here is how I would structure it:

1. In this repository we create a folder docs/social-media/ and put (markdown?) files there that contain the wording we want to use to feature a certain SIG.
2. The features SIG + contribex SIG review the proposed file
3. We merge it, someone with access to our social media (like me) goes ahead and schedules the post
4. Repeat

By building out that folder of templates we can reuse posts, or we can take them as a template for another SIG, etc. So over time we build some experience in doing that, and we have a process that allows any SIGs to sign up and get promoted. Eventually we might need to think about timelines (e.g. only 1 SIG per week, 2 weeks, months, etc.)

[mx-psi]

I think spreading the word across more channels makes sense. Generally making the contributor experience more friendly will also help (improving recognition, making the path to getting to a formal role clearer... will also help).

Getting more contributors is a bit like fundraising for peoples' time. As in fundraising, we will have small donors (independent contributors, contributors that need a one-off thing), but we also have big donors (end-user or vendor companies that invest heavily in OTel's development). Is there anything those two SIGs (or the project generally) can do to make it easier for these bigger donors to commit time contributing to them? The only concrete idea I have here is trying out something similar to Rust project goals, to make it easier for companies to evaluate if committing time is worth it. I am sure there are other possibilities in this space to cater to these bigger donors.

[codefromthecrypt]

On the topic of fundraising, I know some ecosystem players use bounties to get contributors to work on their instrumentation. One has paid like $100-250 to implement certain issues and had bites. Some folks also did work later even if not paid and some worked quite a while for what many would feel is not a lot of money. The gaming/ranking system may explain this.

Anyway, I don't know what sort of funding otel gets through CNCF, but if there is a pile of money somewhere it can encourage folks. If this is an avenue that is a cure worse than the disease, I could also understand that. Just wanted to mention it for completion.

[svrnm]

Note, I labeled this as "for:maintainers", since this is around a service for maintainers (how can sig contribex help them to find more contributor/approver/maintainer), although the individual initative might point to a different group of people, but we can spin this out into separate issues then

[kaylareopelle]

Ruby contrib maintainer here, sharing some thoughts 👋

Lately, I've come to realize our issue backlog is not very contributor-friendly. There's discussions that happen in the SIG and don't get turned into issues. There's lots of work that could be done, but is blocked by a decision somewhere else. Or the work is roughly known (like with signals we're implementing or semantic conventions we're behind on), but there isn't an issue documenting it. I think getting those issues together would be an important first step before trying to direct people to the project.

That work would probably be best accomplished by the maintainers/approvers (we don't have triagers at the moment), but availability for the project seems to be an issue. I have it on my list to do a big issue creation day, but don't think I'll get to it until next week.

I am encouraged that if users run into problems, they seem comfortable opening PRs. It seems like most people (including myself) are interested in contributing if it connects somehow to their day job, but it's a much harder sell to try to participate outside work hours.

[svrnm]

Thanks for sharing your thoughts @kaylareopelle! Having justification for doing code contributions as part of your day job vs justification for maintenance tasks (backlog grooming, making your repo contributor friendly), is indeed a big challenge.