-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[MAINTAINERS] [Action Required] Your help reviewing changes and issues in opensearch-project/OpenSearch #12970
Comments
Thanks for creating this @reta. I would encourage everyone to set their preferences similar to @peternied (https://github.com/opensearch-project/OpenSearch/pull/11600/files). It seems like this would help people prioritize and also make sure they got the notifications they wanted. |
I am doing (1) and (2) 👍 |
Thanks @reta, big +1 to this.
I know it's not exactly the point of this issue, but I would also encourage maintainers who are not able to contribute to change their status to "emeritus" so that our maintainer list accurately reflects who is active. |
I propose we change the status of maintainers that haven't contributed in X time to emeritus to begin with to get the real picture, and close this issue when we have? |
👍 , it is also stated in the RESPONSIBILITIES,md, I think we could set a bar as high as 6 months, wdyt?
|
+1 on moving maintainer status to emeritus if they have not had any meaningful contribution in 4-6 month window. |
I am fine with any timeframe 4-12 months. |
Here is a list for interactions [1] in the past 6 months - who wants to double check the numbers and make the changes?
|
I was curious about some of the numbers (folks who AFAIK stopped contributing after they left Amazon), so I clicked through. It looks like it's counting issues and PRs that:
It does not guarantee that the activity by a given maintainer occurred in the last 6 months. Every "true" contribution in the past 6 months by a maintainer would get counted (since it would satisfy both conditions), so the above numbers are an upper bound. |
I think @msfroh is right, this looks a bit suspicious. I think a contribution from a maintainer has to be something like at least 1 PR they approved or requested changes on. @peternied If you want to turn your script into something more repeatable I opened opensearch-project/project-tools#82. There's existing code that will parse MAINTAINERS.md and makes GitHub API requests easily for you. |
I've created a PR [1] to update the maintainers based on activity for those with no activity on the project. |
@reta I wanted to take a moment to circle back on to this comment with a slight tweak - It doesn't feel like there are many maintainers in the project. What do you think of this position? Dubious methodology aside, the maintainer interaction table [1] says the majority of maintainers are active. We have only a handful of maintainers that are in the less than 10 interaction count. I think this is the project is large enough to allow maintainers to be siloed in certain areas. I do not think the issue is maintainers aren't doing what is expected - but that maintainers are not collaborating together. This issue has 5 out of 22 maintainers commenting on it. I think we are missing some important voices - I'm going to reach out offline to pull more folks in. |
I'm primarily doing "stuff" in .github, with my eyes always on core. I'll occasionally do things like this: #12148 but you really don't want me doing code reviews :) . Do you want to restrict maintainers to just folks who are doing CRs/PRs in code? I'm honestly not offended either way, and happy to move myself to emeritus if folks would prefer that. :) I think the biggest thing that stands out to me is that @reta is more than double the next active person, and that's not sustainable :( I'd like to see some folks on this list like @saratvemulapalli, @Bukhtawar, @shwetathareja and @VachaShah get time allocated in their schedule specifically to work on putting up CRs to help pull some load off of @reta . What do you think @Pallavi-AWS ? |
As the project encompasses a wide scope and maintainers possess expertise in specific modules, the task of reviewing every PR becomes quite challenging. Few options we can have here to get more involvement from maintainers:
|
With the increasing pace of the project, it has been difficult (for me) to stay up-to-date with all that is going on but I am going to commit to doing (1) and find my way through (2) and (3). Thank you @reta for opening this issue! |
I think more maintainers will definitely help and as suggested above with some policy around active contributions in last X months. IMO setting a limit on just count could be tricky as contributions varies in terms of time/effort. |
Thanks @peternied , I don't have any proof to be fair, but it feels like in quantitative measures ("by numbers"), we have enough maintainers (more would definitely help but this is another subject).
Some areas (like remote storage fe), are having a good number of maintainers watching the pull requests and issues out, this is definitely very positive (nonetheless I think having even more eyes would help there). But for most areas lack maintainers attention by large margin. |
Reading through all the comments and thinking through it, I think the problem is not having enough active maintainers. I am all for changing the maintainer status based on their contributions, but that necessarily does not solve for getting more activity from other maintainers, and might even lead to the existing maintainers being further overloaded with reviews and other responsibilities. I think we can break down the solution as follows -
On 2, a suggestion which might be too simplistic and optimistic - but would tagging and assigning maintainers to issues and PRs at random help here? Just thinking out loud here, but if folks have more suggestions on how to improve activity, this would potentially solve the problem. |
While I understand and fully acknowledge the importance of these contributions to tackle operational load, we also tend to overlook, that a maintainer is sometimes also a force multiplier where delivering significant features that shape the overall road map for OpenSearch, requires mentoring newer contributors and building the next set of maintainers. I am not sure if we've noticed but a significant number of RFCs come from newer contributors and some maintainers including myself tend to just hit the like button. I seriously feel that simply counting PR reviews or issues might not be the perfect measure to gauge a maintainer's contribution, what also matters is the impact one's contribution has had on the project. It might undermine not just a maintainer's contribution but contributors who can be good maintainers going forward whose nomination would otherwise be shot down. The point is, we need to honour and respect contributions in its true sense, quality vs quantity. Happy to discuss more. Thoughts @rramachand21 @backslasht @shwetathareja |
+1 to @Bukhtawar's point. Although not a maintainer myself, I have been mentoring and encouraging newer contributors like @sgup432, @bowenlan-amzn, @kaushalmahi12, @niyatiagg, even outside of OpenSearch (eg - apache/lucene#12297 (comment)). I am assuming that is one of the more important responsibility of being a maintainer, instead of worrying about their own PR/commit metric.
1 contribution can be 30 min or few weeks task. The people being chosen for emeritus solely on the basis of number of contributions does not look correct to me. Also, I am not sure how removing the not contributing maintainers (and spending time writing scripts for that) is helping with the original problem of burnout. Is there a limitation on the number of maintainers or this is for encouraging existing maintainers into contributing? Speaking for core search, very few maintainers have the right expertise to thoroughly review the PRs
This does make some sense, but given we have tags for most issues/PRs, notification should be tag based IMO. |
+1 to @Bukhtawar and @jainankitk's point that we should look at maintainer's role holistically that they are contributing meaningfully and not just tie with few aspects or create a leader board of some sort. I don't think we all need to check all boxes but rather divide it among ourselves to be more effective as a group. This issue was created with a positive note on how to enable maintainers to contribute more. Most of the maintainers have expertise in one or few areas. Either, we can add our preference similar to @peternied or encourage maintainers to become more proactive on checking notifications. It would be good to identify areas where we lack maintainer's attention and address them. |
We already have component level triages/meetups, assuming the current set of component that has been identified is regularly looking at the backlog, triaging issues and maintaining operational hygiene. If there is a need to identify more components in a way that splits up responsibilities more uniformly lets do that rather than a leaderboard as @shwetathareja also called out. We are growing and will continue to add more maintainers who would eventually divide and conquer. |
I would also like to highlight the fact that we haven't able to add more maintainers. Since June 2023, we haven't added any maintainer. Apart from more contribution from existing maintainers, we need to think as a team how we can go about increasing the same or is there any impediment we need to remove to solve this. I do see lot of meaningful contributions (RFC, PR and reviews all around) as well as mentoring as well from many folks. Also, to add to @Bukhtawar 's point, we will need more help (more maintainers or help from existing ones) on components where we lack experts . |
I see opportunities where we can streamline the nomination process(I find it to be too open-ended that could undermine great contributions), define guidances on what "meaningful" and "impactful" contribution should look like(maybe quantify impact, making it more data driven), recognise contributors for their unique skills(rather that trying to check all boxes), re-define the veto process to ensure we respect everyones decision and avoiding proximity, recency biases that could unintentionally creep in. I am looking at opening a PR to refine the nomination process and provide clear guidances on how to calibrate contributions. Would love to hear feedback on the same |
Agree @Bukhtawar - a standard criteria for becoming a maintainer would definitely help |
Thanks @CEHENKLE , by no means there was / is intent to restrict that, just siding with other folks - maintainer's role is multifold and every single contribution matters. Please continue helping with these areas, those as important as everything else, thank you. |
Folks, I think the discussions on this issue went off the subject (Your help reviewing changes and issues in opensearch-project/OpenSearch), which is very luckily the indicator of the complexity of the problem space. The only and single goal of this targeted call for action was (and still is) to ask what could be done (if anything) so existing maintainers could be more engaged with the project, specifically with respect of reviewing changes (pull requests) and issues. To finish up on the positive note, I think this issue has gotten quite an attention from the folks during last week, and hopefully we could keep the momentum and direct the engagements towards project operational needs. |
Thanks @reta. I think this discussion pops up in multiple forums so it's best we take actionable AIs from this else we might soon end up in a similar discussion elsewhere. The uber point is how can we better divide up the work and I think we had some good suggestions coming up as well which is worth capturing or following up on |
I can think of two things.
PS: I should plug the fact that I am going to give a talk on "becoming a maintainer" at OpenSearchCon EU in May in Berlin and plan to source ideas from this thread! |
I think it's hard to generalise this, for instance a maintainer can spend 20% time coding, 80% reviewing and mentoring other contributors. This strategy has generally worked better for atleast storage areas where we have been able to scale better by adding more contributors/maintainers and lining others for nominations. We were able to deliver significant features in the last year and have set a decent roadmap ahead. Thats why I feel maintainers acting as force-multipliers are critical from a scaling perspective. A single maintainer writing code most of the time can only do so much.
There is absolutely no need to read every issue and spreading too thin. This is precisely why we have the components assigned and specific triaging meet-ups set up. Maintainers should rather focus on one or more core areas as needed to whilst ensuring all the operational demands are met. This helps foster a deep sense of ownership |
@Bukhtawar I think you'll recognize that if you don't read every issue/PR, you can't possibly feel the pain across the board :) I review/comment/merge on so many contributions every day that it feels like a full time job, precisely because not enough people do that. If I didn't, a ton would fall through the cracks. I think we absolutely need both depth and breadth maintainers, and @reta's sentiment above is very much about this I believe. |
We could organize distinct teams of maintainers for various core functionalities. Tagging specific teams, such as |
The weekly triage meeting [1] is a great way to increase breath for an once a week hour-long commitment. Anyone (+future-maintainers) let me know if you'd like to be on the calendar invite. |
In addition to the above, the component triage meetings are also great way to increase breadth and depth - Any future maintainers and existing maintainers, please do join these as well - for example, next Storage Triage meeting is happening on 18th April - https://www.meetup.com/opensearch/events/299461631/ |
So In the light of component and general triage meetups do we really require maintainers to read up all issues and PR?? @dblock do you think we can give it a try? |
We don't today. All I am saying is that @reta and I do it, and I would say a solid 50% of issues and PRs would stay unattended, or be significantly delayed (many days without a response) if we didn't. @reta LMK if you feel the same, I'd be happy to be proven otherwise! |
I think we should focus on increasing number of contributions (e.g. reviews, comments on issues ...etc) rather than increasing number of maintainers. Penalizing non-active maintainers and moving them out of the list won't help solving the issue. In addition, you don't need to be a maintainer to make contributions into the project. I propose a shift in our approach. Let's implement a system that acknowledges and incentivizes contributions from all members of our community. One suggestion is to compile a list of top contributors on a monthly or quarterly basis, akin to a "Contributor of the Month" accolade. This initiative would not only spotlight the efforts of dedicated individuals but also foster a sense of appreciation within our community. Celebrating these achievements collectively can serve as a powerful motivator for continued engagement and growth of contributions. |
Thanks @reta for this. I haven't been active lately but I'd more involved and interested in (2) in all things plugins. |
There is simply too much noise and not enough use of tags to help bring attention to what needs attention.
What would help me get more engaged:
|
Is your feature request related to a problem? Please describe
The OpenSearch core development pace has accelerated significantly, thanks to large, and growing, number of contributors from half a dozen organizations. Unfortunately, out of 30+ listed maintainers, only a bit over a half have had any engagement in the past few months in both reviewing and merging pull requests or contributing code or content to the project. We understand that everyone has jobs and responsibilities outside of the project, but kindly ask the maintainers to step up by engaging with the project.
Describe the solution you'd like
Related component
Other
Describe alternatives you've considered
No response
Additional context
The risk of burnouts is real
The text was updated successfully, but these errors were encountered: