Having two versions of FCC (live and beta) puts off contributors

I have identified issues with some of the challenges on freecodecamp.com, but I am unwilling to implement their solutions, or even raise those issues, because the Contributor’s Guide says work should be done from the staging branch, and the website on the staging branch is different to the one being served as freecodecamp.com. There is no guarantee that the same issues will exist on the staging branch website, and after checking one once and finding that the issue didn’t exist, I’ve lost the will to do it again.

I suspect that this is causing FCC to lose contributions (and even contributors) that would otherwise help learners who are struggling with issues on freecodecamp.com today (issues that have and haven’t yet been identified both). These learners turn up in the chat rooms, which is how I’m discovering these issues.

I suggest that having one single version of the website would solve this problem. At its worst, two versions of the website mean you’ve got one that everyone’s developing, and one that everyone’s using.

2 Likes

Check for your bug on the Github issues page to see if it’s being/been addressed. If not, you can create a new issue and offer a solution. If it gets accepted, then you can proceed with confidence. This is standard, and it’s not going to change.

1 Like

There are only two versions because there is a big expansion happening. This is the 2nd time FCC has had a major expansion and that’s a good thing. THe goal is obviously to have “one version”. but when there are major updates or additionals planned, or for examle when FCC changed from MEAN stack to MERN stack…and 2nd beta version makes sense. If it was a smaller upgrade it’d take less time to merge into one site, but then that would be happening often.

Check for the issue in the issues page and if you find the bug carry on.

3 Likes

Why should I spend time reporting an issue with the version of the website in use when I’ve no guarantee it will be an issue on the website in development? Sure, I could spin up the development website to check, but the project will lose contributions from people who aren’t willing to do that.

Then don’t. I don’t understand why this seems to upsets you so much. Great that you want to contribute, but if FCCs growth means that the current system makes it too hard to do so then stop worrying about it.

Here’s an example, last week someone posted in the forum about a dataviz challenge. He and another spent time agreeing about an improvement that should be made.

That issue exists in the current version, but had they searched for issues on github, they would have seen that issue has been addressed already and saved themselves lots of time.

Instead they wasted it, which seems to be a real concern of yours and is a theme in your posts.

If you want to help and don’t want to take the time to spin up the current version, search the issues:

Getting a local copy of FCC working on your laptop is not the only way to contribute. (Besides, how long does it take? Clone, npm install, run mongo, that should do it I think) a few minutes

It seems like your spending a lot of energy finding ways to complain when the way to contribute takes far less energy.

5 Likes

You don’t have to spin up the app to check, you just search the issues page I linked to. This is the process described in the wiki, linked to from the FreeCodeCamp repo: https://forum.freecodecamp.com/t/how-to-report-a-bug/19543

Let’s be clear, even if the FreeCodeCamp volunteers threw out every sane practice in project management and stuck with just one, single live version of the site, you could not contribute without following the same steps. You have to communicate with the development team about what’s needed, why, and that you’ll do it. “Surprise! Here’s a pull request!” is not good practice. Bug hunting is awesome, though, so if you’ve found a bug then it’d be a great if you could check the issues page and report it if it’s not found.

2 Likes

Step by step:

  1. I notice a problem on freecodecamp.com.
  2. I look in the repository to see if someone else has already raised the issue. If they have, fine. If not, it’s up to me to raise the issue. I’m used to this.
  3. I raise the issue and decide to have a go fixing it. I’m told by the Contributor’s Guide to develop on the staging branch. I spin up the website on the staging branch, and the issue no longer applies because this is a different version of the website. My time so far has been wasted.

So every time I notice a problem on freecodecamp.com, I also have to check if it’s a problem on a different version of the website. This extra hurdle can only discourage contributions, and I’d have thought that receiving as many contributions as possible would be FCC’s top priority.

I’m just trying to make the lead developers of FCC aware of this problem, as a contributor.

2 Likes

@PortableStick and @AdventureBear thanks a lot for your comments and contributions.

@WillWhite:
Thanks for the honest critique of the processes that you have felt while trying to contribute. While other’s have surely considered your comments as a rant, trust me I can understand your frustration (I have been contributing to the repo a little over a year and a half now, and with a little trust from others am an issue moderator).

Here is my understanding of the situation: Yes, it’s messy. Yes, you will probably find issues, and that will not exist on the versions that are in development.

And as you rightly said that this may discourage contributors like you to NOT consider or bother coming back.

I agree. And I am sorry (at least on a personal note).

But, this is Open Source, it’s always crazy and it shall always be. We have through several pitfalls found the current approach is a steady way to grow. And just for the record, I have seen the no of contributions grow exponentially.

As a moderator on the issue tracker, I often lose track of open issues and pull request alike if I am away for a few days. Yes, its hard and frustrating, and that proves that there are so many contributors making us restless, to build and fix things.

So, yeah on the contrary to what you feel we aren’t losing contributors, and we are absolutely excited about (lol… with me being thrilled about it).

But, that said, I understand that there is the confusion that needs to be clarified with respect to anyone in your position. Sorry for the delay but, here is the much-needed explanation:

  1. freeCodeCamp.com is the version that is known as master branch on the code repo which we also refer to as production.
  2. beta.freeCodeCamp.com is the version that is known as staging branch on the code repo which we also refer to as beta.
  3. There are some other branches, but it’s not very relevant to this discussion.

The difference between beta and production is that the former usually has changes that will be a major overhaul to the current production, or change the user experience of the site in a way that will be radically different that previous.

Currently, this is the 400+ new challenges and the high performant UI of the website.

The reason to do this is that beta is our testing ground. The main production website has over 400,000+ active users, including schools and colleges. We can’t simply break their flow just like that by pushing things that we have in works.

Hence, what you see on the production is different on the main website.

Now that’s sorted lets, discuss how do the team decides which issues are to be fixed in beta, and which in production?

  • If it’s a blocking issue, like the user can’t go ahead anywhere without an urgent fix, it goes to the production (master) after its fixed in staging.
  • If it’s a security issue, that needs a patch, then it goes into the production (master) after it goes in staging.
  • Everything else goes into the staging.

Okay, hold on a minute. You would ask why not fix it in master as well? Simply, because the master is going to get updated with regular fixes from staging when the beta is deemed okay by the contributors and the team. And also, this ensures that we do not miss any changes when we MERGE the beta into the production in its release.

It’s a lot of technicalities perhaps, but trust me this has ensured that we have continuously updated the platform with features and fixes.

Now coming to your role as a CONTRIBUTOR:

  • You report anything that you feel is an issue on the tracker, whether you are interested in fixing it or not.
  • We ensure to get back in triaging, where this fix or feature goes as per the status of the development we have above, basically, we let you know, the validity and the criticality of the reported issue.
  • The issue id then labeled for pull requests, which you or anyone interested is free to make.

Let’s say you are not interested in either of these or are thrown off by the seemingly complex process, you are more than welcome to drop a line anytime in the contributor’s chat room or perhaps in this forum. Someone from the moderator’s team will report it to the correct channel (which is also a huge contribution on your part).

Contributing to the codebase is just a tiny little thing, what’s more, important is just letting someone know that there is an issue! There are so many who would take the lead and get to fixing it because its OPEN SOURCE and it absolutely rocks, even though it’s frustrating at times, its fun to know that something that you said affects so may people and helps make the platform a little better.

Cheers, and sincere thanks for your concern, we take your feedback and will consider making the process more friendly if possible.

Happy coding!

9 Likes

I’ve come to understand that the motivation behind the beta is to use React. Using a new technology is fine, but it should be kept separate from the content contributions.

Hi @WillWhite I am afraid, that this is understanding is incorrect, the philosophy behind using React is not because its new and trending, as matter of fact its one minor part of having a High performant UI.

Let me clarify the logic for the sake of everyone.

@BerkeleyTrue wrote a nice article about spikes that we used to get in our concurrency rates during peak times, we jokingly called those busy Mondays I believe.

This basically comes down to the fact that we are growing and growing real fast, upto a tune of 5000 new registrations per day I think. And all of the action actually happens in the browser of the user. The server side stuff is mostly updating and saving the data, and there is very little hard core computation.

This means we need a approach that can help us scale while keeping our costing as low as possible, if we want to keep ourselves to be offered to the community for free (we are very serious about this one rule).

We want to have a platform hopefully soon:

  • that is flexible enough to deliver the content to any device in an offline format ideally.
  • is open to have client applications around the curriculum. (Also known as our Open API initiative in works).
  • scalable to user growth, by separating the API and web app.

The beta is a refactoring in that direction. It hence relies on decoupling of the web server into an API server and a web app, meaning fewer requests to our backend.

…but it should be kept separate from the content contributions.

I am very much inclined towards this suggestion, which is an excellent thought, and believe me or not that’s where we are headed.

We have some ideas already in brain storming and prototyping around that, I can’t reveal much right now (remembering not to count chickens before they hatch), where in we will have a API that can be used by the community to build things around our open curriculum and that does not limit it self to the challenges on the platform, but our video content, the wiki articles, and all sorts of things.

Refer: https://twitter.com/ossia/status/818900782825213952

Stay tuned.

Thanks again for your feedback!

2 Likes

Thanks @raisedadead for explaining here the motivation behind using React. The only point I meant to make was the second one (that tech and content should be kept separate).

It’s occurred to me that there is an additional disincentive to contributing content to a content-tech beta: if somehow the tech never makes it out of beta, the content I contribute may never see the light of day.

I’m interested to know if there is an established development practice that deliberately avoids a project having two versions of itself, or at least two versions of its content.

1 Like

Sad to know that you feel this way, and I see where you are coming from. I could not agree more had I not been on the internal team. I would also agree that it definitely WON’T if the 600+ contributors on the repo did feel the same way. That ratio is not large considering we are teaching 400K people to code every month. And we don’t possibly want people to be discouraged at all.

I do get that yes, going forth we should split up the curriculum as recommended by you.
What I don’t seem to get is, that won’t get to the main website any way without the new infrastructure. For instance we are trying to have ES6 challenges inside a browser. This is something that does take time to build up.

Yes, I will definitely point this to the team that we SHOULD separate the content and the infrastructure. Its an excellent advice no doubt.

I admit, that things on the platform have been slow, which have resulted in the judgment you rightly make. But that said, if you happen to check the progress on the curriculum then almost all of it is done by contributors who have never contributed to Open Source.

Whenever the beta is released, you will notice some of the things but I’ll list them to give the scale of overhaul that has happened in a year:

  1. React Infrastructure for performance, of course.
  2. ES6 Challenges in a browser environment (which is not supported natively).
  3. Modern Frameworks and Libraries (which need their own support structure).
  4. Scaling up the backend to support 700,000+ registered accounts.
  5. Testing infrastructure the front end projects (earlier we relied on manual code review).
  6. Bringing in more secure authentication mechanisms.
  7. Moving away from dependencies on multiple third party sites for teaching the backend courses to a well committed team at Gomix.
  8. Providing support for Video tutorials and curricula from our Youtube channel which has gotten large with a ton of content.

We need your help in making better content. And we need your help in making the infrastructure that needs to be in place for it too.

And we do accept that we should be making this as user friendly as possible.

But as of today the policy stands, the curriculum comes out of beta whenever its ready! However long it takes. We hope you would respect this and come forth in contributing.

As always thanks a lot for the honest feedback that we have been needing so desperately, to make your experience better.

Happy contributing!

2 Likes