@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:
-
freeCodeCamp.com is the version that is known as
master
branch on the code repo which we also refer to as production
.
-
beta.freeCodeCamp.com is the version that is known as
staging
branch on the code repo which we also refer to as beta
.
- 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!