Remove mentoring docs/issue template

[terrytangyuan]

I am considering removing the mentoring option and related docs going forward. Any objections?

Reasons:

• We got a lot of mentoring requests and do not have many active mentors.
• They often become stale and frustrate new contributors.
• We should encourage people to comment on existing issues that they are interested in working on.

[agilgur5]

• We got a lot of mentoring requests and do not have many active mentors.
• They often become stale and frustrate new contributors.

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: https://github.com/argoproj/argo-workflows/issues/9027#issuecomment-1312922662), 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. Perhaps it was more viable in the past, but right now, I am surprised it exists given that so many requests are marked as stale. I've never filed a mentoring request myself, but it frustrates and disappoints me as well to see that. And when I respond to an old mentoring request about an issue I stumbled upon, I am apologizing that their request was never responded to timely (even though their request and the program pre-date me).

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). At the very least, I think it would be good to narrow the scope of the program (perhaps significantly).

As a point of reference, Argo CD does not have a "mentoring program" despite having more contributors and more interested community members.

• We should encourage people to comment on existing issues that they are interested in working on.

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.

[isubasinghe]

@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).

[terrytangyuan]

That's another topic. Do you have any alternative proposal that works better than stalebot?

[isubasinghe]

@terrytangyuan I'm not sure we need stalebot, quite a few FOSS projects without it.

[agilgur5]

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: https://github.com/argoproj/argo-workflows/issues/9027#issuecomment-1312922662), yea can just remove it entirely.

Here's a few hypothetical scenarios:

1. There's a bug
   1. It's not fixed. There's no point in closing it as stale.
   2. It's fixed. It should be closed regardless of stale or not.
2. There's a feature.
   1. It's not implemented nor rejected. It should not be closed as stale.
   2. It's either implemented or rejected. It should be closed regardless of stale or not.
3. There's a PR.
   1. It hasn't gotten a response or is awaiting review/merge. It should not be closed as stale.
   2. It's gotten a response and needs more work. This can be marked as stale and eventually closed out if there is no further work done. If it's a good improvement, it can also be left open for someone else to take over and just marked as stale and not closed (until there is a superseding PR).
4. There's something else (e.g. the very recent support label, or the mentoring label in the past).
   1. It's hasn't been answered or responded to. It should not be closed as stale.
   2. It has been answered or responded to sufficiently. It should be closed regardless of stale or not.
   3. It has been answered partially, but needs more information. This can be marked as stale and eventually closed out if there is no further response from the author.

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've gone through stale PRs as well and plan to revive some of them when I have some time. I've done the same in argo-ui as well. Still got more to go in both repos.