-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Remove mentoring docs/issue template #11802
Comments
As mentioned over Slack, I'm for this as I think the current implementation / execution actually gives a bad impression and has the opposite of its intended effect, making people less likely to contribute. Given the docs and templates (and their wording), the "mentoring program" sounds very robust and it seems like a mentor could potentially dedicate a lot of time to a mentee (especially when mentioning sync calls etc). But given the lack of people able and willing to mentor compared to the amount of mentoring requests, I think this gives a false impression. Or, putting it another way, it feels misleading. Stalebot is already not well liked in OSS (including by me, but that is a separate topic. note that I found that link in an issue in this repo: #9027 (comment)), and having stalebot further mark your mentoring as stale when you never even got a response could feel extremely frustrating, disappointing, and even agitating. In my opinion, I think it's better to not have a mentoring program than have a misleading one that has the opposite effect of its original intentions. In some cases, it also creates a bottleneck as able contributors file a mentoring request and wait for a response (that never comes) instead of making a draft PR or responding to an issue (with questions that could potentially help other interested community members) etc. That is just my two cents of course, and I am a more recent contributor, so can factor that in as well (in either direction). As a point of reference, Argo CD does not have a "mentoring program" despite having more contributors and more interested community members.
I think most mentors already do this anyway (including me), so one option would be to more explicitly document this and more clearly communicate that draft PRs and clarifying questions on issues and PRs are totally fine (there is still a bit of a PR backlog though). Along those lines, one option would be to redirect the mentoring template to a docs page that explains how one can ask for help and interact with issues and PRs. The mentoring docs page can be rewritten to match that representation. |
@agilgur5 I just wanted to chime in on something related, Stalebot is awful and we should remove it imo, I've had a lot of PRs etc get ignored for quite a while and then eventually closed. I think its quite annoying/disheartening to have your efforts ignored like that especially if its volunteer work (I am paid though, nevertheless I find it demotivating). |
That's another topic. Do you have any alternative proposal that works better than stalebot? |
@terrytangyuan I'm not sure we need stalebot, quite a few FOSS projects without it. |
It is a separate topic, that's why I didn't really go into it in my first comment. Per the linked blog post I shared above (which I actually found from a comment in an issue here: #9027 (comment)), yea can just remove it entirely. Here's a few hypothetical scenarios:
So out of 9+ possible scenarios, only 2 of them are potentially appropriate to be closed out as stale (IMO). Otherwise, marking them as stale and closing them when there was no response just ticks people off while also potentially creating false negatives (e.g. on bugs) or causing folks to create duplicates (which is the opposite of helpful or encouraging). I don't use stalebot in other repos I maintain, and usually just go through this kind of "flow chart" / thought process when looking at an old issue or PR. Also, as another point of reference, I have quite literally been going through dozens of bugs in this repo that were marked as stale and closed, removing the label if it were actually properly closed out (which is many) and referencing the PR that closed it. Those that were just closed as stale and never fixed may actually still be active bugs. |
I am considering removing the mentoring option and related docs going forward. Any objections?
Reasons:
The text was updated successfully, but these errors were encountered: