Freecodecamp: Contribution guidelines and workflows need clarifications.

[theoutlander]

Issue Description

I have noticed over the past week and a half that it is difficult to find issues to work on without stepping on toes or waiting to hear from someone several hours later if it's okay to work on it. In many instances, I've ended up playing with something that was marked as Help Wanted and unassigned and in the Todo bucket, only to realize that someone else was working on it!

Work-items should reflect current and accurate status. I would like to see the following:

1. People working on issues need to be assigned to it, or at least a note stating that a specific person is investigating needs to be posted.

2. The issue must be moved to in-progress (or in an investigating bucket)

3. The issue needs to be tagged appropriately

I spent a week trying to get started because I couldn't find an available issue to work on and almost gave up.

[theoutlander]

For example, #16235 states "Help Wanted" and is in the "To do" bucket. However, I've been working on it for a few days now and have also submitted a PR earlier today.

[theoutlander]

In addition, it would also be nice if issues were tagged with complexity. For instance, I want to tackle the most difficult problems that nobody else wants to take. ;)

[vkWeb]

@QuincyLarson Please tackle this :).

[ncaron]

It would be nice if users are able to assign themselves to issues so others know it's being worked on. There could be a rule like you can't assign yourself to more than 2 issues at once to give the chance to everyone to work on something.

[raisedadead]

We have had considered this assignments in past. Unfortunately that has certain limitations:

• GitHub's search (within the assign to box) is heavily limited. It most often than usual doesn't show up the username (unless they are member/collaborator).
• It doesn't guarantee that an assigned user will submit a PR (due to so many reasons).
• This is a hard enforcement on both maintainers too, to keep checking, assigning, etc.

I can see only two solutions (cumulatative):

1. Automate the task movement etc. which may be buggy in many cases.
2. Keep the current policy, that is whosoever makes the first PR is considered to be working on it. Followed by commenters on issue thread with mutual understanding of working on it if PR is not available. That is, if someone said they are working and haven't updated their status, anyone interested should just comment, hi @someone! are you still on this? would you need some help? I am available, and ready with a solution

That said I 100% agree we can improve the docs/guidelines to follow and mitigate such scenarios and the labels to be more meaningful etc.

Thanks for this report. We will keep this under discussion and update when we are able.

[raisedadead]

It would be nice if users are able to assign themselves to issues so others know it's being worked on. There could be a rule like you can't assign yourself to more than 2 issues at once to give the chance to everyone to work on something.

This is a hard enforcement. And will draw a lot of conflicts, diverting the focus from actual contributions.

We agree, that we can simply have guidelines to do so and mitigate things.

We are listening to the feedback, but please bear with us, while we are able to draw some policies for the community.
We of course want to be welcoming to everyone. I Personally feel this is very critical.

Thanks a lot.

[theoutlander]

If contributors get the run-around to identify which issues they can work on, it is going to be detrimental to the long-term success of the project. I certainly can't waste my time trying to identify what to work on next.

Also, I don't understand your statement about git hub search related to assigned users. Maybe we should consider using Zenhub instead.

[raisedadead]

If contributors get the run-around to identify which issues they can work on, it is going to be detrimental to the long-term success of the project. I certainly can't waste my time trying to identify what to work on next.

Yes, that's well established and is the point of this threads discussion, and we certainly aim to address this by improving the clarity around it.

That's the real solution here, without the added burden on anyone.

Also, I don't understand your statement about git hub search related to assigned users.

Search is always your friend. Its a feature.
https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/

Maybe we should consider using Zenhub instead.

Some of us use it (including yours truly, for over a year now), and I don't find it any different because the ones not using (which the huge majority of contributors) will not see its flow since that will not have the extension.

[QuincyLarson]

@theoutlander Thanks for your feedback. I'll add to what @raisedadead a couple quick points.

Assigning issues doesn't really work, because we can only "assign" in GitHub an issue to someone who has previously contributed. For example, if I try to assign tenderlove - a prolific contributor to open source - to this issue, GitHub won't let me. Rather than assigning, our system is this:

1. Someone wants to work on an issue. They say so in a comment on that issue.
2. If they don't post an update in a few days, we nudge them, by saying "hey, are you still working on this?"
3. If they don't respond, we see if someone else wants to do it.

Having a system in place isn't going to change the fact that most prospective contributors don't ever end up opening a pull request.

But I think we could start applying the "in progress" label to any issue someone is currently working on. Then if that person stops responding or reporting progress, we remove the "in progress" label and re-add the help wanted label.

This way, at least we'd know whether someone was working on an issue by looking at the labels, even if we can't assign that person to the issue using GitHub.

@ncaron @theoutlander @raisedadead What do you think of that system?

[raisedadead]

Yes, that definitely makes sense and we should update the contribution guide to reflect this and maybe adding a couple difficulty level labels as requested in this thread by @theoutlander earlier should be good.

[theoutlander]

Thanks. That sounds reasonable. We can close this issue unless there's more to discuss.

[Bouncey]

Is it possible for camperbot to issue in progress and help wanted labels?

Maybe using a magic phrase like "I will work on this", camperbot will apply an in progress label and perhaps comment that if a PR has not been opened after a set amount of time, the issue will be opened up again with a help wanted label?

[QuincyLarson]

@Bouncey Yes - I like that idea. We should do that. Camperbot can automatically add labels based on perceived intent and look for a few key words.

@raisedadead We should only have two difficulty levels: beginner (first timer only) and normal help wanted. I say this because it removes the need for both the person creating the issue to understand difficulty, and it removes the need from contributors to interpret the label.

We don't want random campers who've never opened an issue before trying to judge the difficulty of an issue.

"First Timers Only" is unambiguous. And these are special issues that seasoned contributors like yourself come up with (who have a better handle on the complexity of various tasks), so I suggest we continue the way we're currently doing that.

[QuincyLarson]

I'm closing this issue as stale since it hasn't been active lately. If you think this is still relevant to the newly updated platform, please explain why, then reopen it.