Freecodecamp: Every Challenge Should Link to Related Github Repo File

[gwenf]

It would be great if, for each page or challenge, we had a direct link to the github code to make changes to that file. For example, the Vue.js documentation has this at the bottom of pages:

Sometimes, people find an issue with a challenge or page on freecodecamp.org and we should make it easy for them to go and edit that file and make a PR with their changes.

[RandellDawson]

We are working on something like this for the version 7 of the curriculum. As far as the current curriculum, I am not sure where the text would go, so that it does not further clutter the challenge description/instruction text. The last thing we want to do is make the text in the challenges any longer.

[gwenf]

@RandellDawson I don't think it would be too obtrusive to put it in smaller font right below the title or at the bottom of the challenge description. It's just a few words and one link.

[RandellDawson]

I will discuss with the core team, but since we will have this in the new curriculum, I think this will not be a popular idea for the existing curriculum. We really just do not want to distract from the challenge learning task.

I will let you know what the final decision is.

[gwenf]

Thanks. Someone just mentioned it to me earlier that they wanted to recommend updates to challenges but didn't know how to get started with that.

[raisedadead]

Thanks a lot for this suggestion Gwen.

I agree that finding a challenge to update quickly has not been the best of the experience. To be honest it is intentional. We used to have a Wikipedia style guide where users could do something similar, they would click the link on the bottom of the guide and edit the page.

Here are some reasonings based on my experience over the years (and the archived guide project):

1. A link back to the source encourages updating the file quickly if it doesn't "seem right" to users. People typically tend to edit things without discussing and sending in PRs.

   It's a form of cognitive bias, if you will.

2. It bypasses the existing workflow about learning how to edit the files. More often than not you would need to validated the changes on a local/online setup of fCC before sending PRs.

   This means users will not read the documentation around the challenges and instead look for the markdown, edit it and leave the onus on us maintainers. This becomes noise really quickly where you have to reject PRs.

I know that is not the intention of your suggestion. Users should be able to recommend updates, fix typos, grammar etc. but making it "too easy" has unwanted side-effects I mentioned above.

Here is what we should do:

We could think about some form of UX element that talks about discussing bugs in the forum, issue tracker --> then creating PRs.

We already have this as the Read-Search-Ask, but I am open to improving it a bit.

What do you think?

[moT01]

We could possibly add a link that opens a new issue with some prefilled info - like a link to the challenge and maybe to the file in the repo. But even that worries me that we will get a bunch of people reporting issue's when there's just a problem with their code. Just a thought.

[nhcarrigan]

Currently a user can hit the "Ask for Help" button to generate a forum post. My understanding is users should be turning to the forums first for triage with their code - if the community determines it is actually a bug in the challenge, then an issue should be created right?

We have a canned forum reply for creating GitHub issues for challenge bugs - which we use when we determine a user's code should pass. I agree that bypassing this workflow and adding a CTA on the challenge page for creating issues may lead to an influx of inaccurate bug reports.

[RandellDawson]

@nhcarrigan is spot on. We want users to use the forum for debugging their code. We already have to close PRs for users creating issues on GitHub when the issue is the user's code. We redirect them back to the forum. On a related issue, mods on the forum should only be recommending opening GitHub issues, once they confirm themselves that there is not a bug in the user's code. I have a few mods recommending users to create GitHub issues without validating whether or not the user's code is the source of the problem.

[gwenf]

@nhcarrigan some users don't need help. Maybe they want to suggest wording or example updates for the challenge. Many people still have a hard time understand some of the instructions for freeCodeCamp challenges so the extra PRs/suggestions could really help. Many teachers also audit the freeCodeCamp challenges and it would be nice if we could just click on a button to suggest updates to how the challenge is written.

[gwenf]

Here is what we should do:

We could think about some form of UX element that talks about discussing bugs in the forum, issue tracker --> then creating PRs.

We already have this as the Read-Search-Ask, but I am open to improving it a bit.

What do you think?

Thanks, I agree with your proposal about the UX element. It could guide users to either opening a forum post or an issue. As I mentioned above, many users of freeCodeCamp are not first-time learners and it would be great to capture their suggestions as issues, and then hopefully PRs.

[TheJaredWilcurt]

I am very much on board with this. I've been going through the curriculum and just finding lots of small things that would be easy to fix if there was something like an "Edit this page" link that takes you to the file to edit on GitHub and submit a PR.

I understand that it may be a concern that new learners may misunderstand and misuse this feature, however, rather than not do it, I'd suggest just putting a flag on the feature and trying it out. If you get overwhelmed with lots of junk PR's from people misusing it, then just turn the flag off and find a better UX solution to get the same benefit.

There are clear benefits in letting people more easily improve the content. Hypotheticals should be considered, but shouldn't be blockers for progress.

[nhcarrigan]

@TheJaredWilcurt the concern with streamlining the process directly from the /learn platform to the file to edit is that it disrupts the general workflow as @raisedadead mentioned:

It bypasses the existing workflow about learning how to edit the files. More often than not you would need to validated the changes on a local/online setup of fCC before sending PRs.

I think adding a CTA that leads users to create an issue would work, but not to edit the file directly. Most changes to the codebase require testing locally prior to opening a PR, or the CI tests will fail.

[raisedadead]

Thanks for your feedback again @gwenf and @TheJaredWilcurt

We understand and empathize with the need here.

Like I mentioned before, we have had something like this in the past with another project. And we were overwhelmed at the time with the noise.

Valuable contributions such as yours, who are not students for example would simply get in lost in the noise of the PRs if we skipped to "edit this file" and be done with it.

We would instead welcome any alternative UX ideas that ensures two things:

1. Makes it dead easy for users to recommend a change.
2. Enforces the workflow we have in place to validate that the change passes the tests we have in place with the existing workflow.

This is not a hypothesis. I am citing this from my experience with a similar setup in the past.