jiebi/CodeConvo huggingface dataset:
I'll copy my other comment here, so we can have a discussion in a single place:
If we aren't going to enforce/test it, it's just pointless noise that needs to be removed. Text that doesn't related to what is being tested just fills the screen. We have enough trouble getting users to actually read the challenge text without including text we intend for them to ignore.
From an accessibility perspective, I don't think we should be strict on formatting that does not affect the execution of the code. One example that comes to mind is people who are listening to the code. Screen readers don't announce spaces by default so it might not be obvious that there is an extraneous space between the variable name and the bracket notation. I don't think the tests should penalize them for this when the code executes just fine. On a side note, you can use the keyboard shortcut in monaco to format the code and it will remove the space between the variable name and brackets (I just tested it). So I suppose we could require everyone to format their code properly before testing, but this seems like overkill. Or perhaps there is a way to auto-format the code when the user clicks the test button?
I'm not thrilled about intending this syntax to pass, but I find the accessibility concern more compelling than just allowing highly uncommon syntax variations because it can run in other JS environments. But I still say that it we aren't going to test it, then the spacing note should not be there. If its not part of the challenge outcomes, then it's noise. We already struggle to get learners to actually read the parts of the text that relate to their ability to pass the challenge.
Allow me to revise my previous answer just a little. I think I was assuming that this extraneous space issue was being tested in all challenges, but now I'm realizing that it may apply to only this one particular challenge. If so, then as long as the challenge instructions make it clear that this is a requirement to pass the challenge, and there is a clear error message that indicates the reason the test failed is due to the extraneous space, then I think it is OK to leave this test in there if it's deemed important enough to keep. But in general, I do not think such formatting issues should cause a test to fail (as explained above).
Thanks for the thoughts & Here is what we should do: the note.
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --Describe your problem and how to reproduce it: The test error messages do not indicate anything about resolve and reject’s strings. This may throw some people off as the message error just indicates the if statement did not fire. Add a Link to the page with the problem: Test Code: Tell us about your browser and operating system: Browser Name: Chrome Browser Version: 4044.124 Operating System: iOS 81.0.4044.124 If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box): ! !
Hey , I just looked at the page, and want to make sure I got this right, Currently, the test cases only pass if "We got the data" and "Data not received" are the strings inside resolve and reject; if anything else is entered in then the tests fail. If I'm correct, the strings don't really matter, it's just having resolve and reject inside the if and else statements with a string inside. I just wanted to clarify what is needed before starting. BTW, I'm a CS student who's just getting into Open Source and thought it would be awesome to contribute here! I've used freeCodeCamp in the past to help me learn the basics of Web Development, and it really has changed how I look at coding overall. Attached are a couple of screenshots of what I tested. <img width="1540" alt="Screen Shot 2020-05-09 at 2 24 41 PM" src="https://user-"<img width="1533" alt="Screen Shot 2020-05-09 at 2 28 13 PM" src="https://user-"
Hey Thanks for jumping in! The instructions do say that the string does matter, however I believe the test messages should have something pointing the user in the right direction. Eg: Perhaps additional tests should be created for edge cases IDK . The file that needs to be altered for a PR should be:
Just my two-cents: As much as it would reduce posts asking for help on the forum etc., many (if not most) of the challenges require the user to be precise, and follow instructions well.
Sure, we could change many tests in other challenges, but I would much rather have the tests as is, teaching users to debug their own code. In programming outside of tutorials, debugging is a massive portion of the process, and programmers do not always write their own tests. In my opinion, the tests are well-suit for teaching programming skills.
Just took a second look and it makes sense now, didn't see the part that specified what the strings had to be. I'll probably just add a couple of tests to check for what the strings are inside of resolve/reject and change the test messages depending on which ones were passed. BTW, if you don't mind me asking, why do you guys have all of your files in Markdown? I'm just curious for the sake of learning.
That’s a question or or some of the moderators could artIculate a better answer, but I think the theory is that markdown is an easy to read input for feeding the curriculum engine/logic.
TL;DR: Markdown is easy on editing. We used to have a json object (schema) for the challenges in the earlier days, but ever since we moved to - A static site generator, we started using markdown. It is easy for contributors to edit a text file. More often than not when making a quick contribution, you do not need to know how the underlying infra works, because maybe you are changing the instructions a little bit, fixing a typo, you get the idea. We wrote a custom parser (and a schema that it needs to be compliant with) to get the content out of the markdown and build the HTML pages (which is implemented as a Gatsby plugin of course). You are welcome to dig into the package to learn how it works. P.S: All questions are welcome, do not be shy :)
That makes a lot of sense thanks for the response, I have a couple more questions actually If you don't mind me asking, Since the challenges are made using Gatsby, how do you guys test your code? Do you make your own site and run it on there? Or do you use extensions on whatever IDE/text editor you use? Also, what does YML mean? I'm assuming YAML, but I honestly don't know, I think however that If I know what that means I can figure it out.
Here's what I have so far:  What I want to do is change the first two tests to just resolve and reject with empty strings inside, then have the last two be with the correct string inside. These are probably very simple questions but I think they would help me out a lot as I contribute more this summer!
have you made a PR yet? When you do put the PR # in this thread so we can test your tests. If you need any help with this let me know. EDIT: Yes, YML stands for YAML files (yet another markup language). If you read the instruction on installing FreeCodeCamp locally there should be instructions for testing locally as well. To test curriculum: To test everything: Check out for all the commands for the project.
Also we have some documentation here: if you want to learn more.
I'm working on setting up my repo locally and getting a basic idea of the codebase, as I've never worked with YAML; if anyone else wants to fix this issue don't hesitate! I can work on something else. Like I said I'm new to open source so all of this stuff is new to me, apologies for me taking this long, I will be a lot more productive once I have more time on my hands.
In step 31 of the Learn HTML Forms by Building a Registration Form project, the step doesn't explicitly say that it wants the input element to be nested inside the label element. Instead it says: "Add a label with the text Upload a profile picture: , and add an input accepting a file upload." This could be interpreted to mean that the input element should be on the right side of the label element. Only when we attempt this are we told by the Hint "You should nest an input element inside the label element." To clarify the requirement, the step should use the word nest in the exercise as below for eg.: "Add a label with the text Upload a profile picture: , and nest an input accepting a file upload within it.", The step should explicitly state that the input element should be nested within the new label element. No response Not Applicable No response
I think if all of the challenges will have specifications defined explicitly, it will serve no purpose of "challenging" the learners to really think and solve it. In the first place, the solution is already implied from the given code and then, if the learners will still have the hard time solving it, then the feature will definitely do its job.
Agreed. The instructions should be clear to begin with. Making the users guess what the test requires isn't a "challenge", it's just rude.
For what it is worth, the camper has nested an input in a label element a few times in this challenge prior to this step. I am not against adding this reminder to the instructions, but I don't want to lose sight of our goal to keep the instructions more lean and have the hints serve as the reminders.
Definitely. But I looked back at the instructions on the steps where they add the previous inputs and we do explicitly tell them to put the input within the label: step 17: Nest an input element within each label. step 25: within each of the first two label elements, add one input element with type="radio". If we can add that information to those instructions then I think we can add it to this one. And let me just clarify that what I am really concerned about is this correct solution being rejected: I'm working under the assumption that correct code should always pass. So we need to tell the user that only a nested input will pass if that's all the test will accept.
The instructions state "In your fourth tr element, add a th element with the text Total Liabilities." However it is not really clear that the user should or should not include a period. Users will have failed previous tasks if the period was omitted (periods are required on previous exercises) , therefore they will most likely add the period which will result in a failed test case. Also, if the period is included after "Liabilities", the error message gives "Your th element should have the text Total Liabilities." Which does not highlight the actual issue. Maybe making a different test case message that looks for the period would make it more understandable? The code above should highlight the issue of the period being present. The test case that is currently in place can confuse users that they have a spelling issue/spacing instead of the actual issue being the period at the end of "Liabilities". No response Device: Desktop OS: Windows 10 Browser: Chrome Version: Version 108.0.5359.125 No response
I was thinking, that we could change to But this doesn't make a coherent sentence. I am in favor of adding a new test.
I also think a new test case would be good.
Hi! We just opened a to fix it, but it was not accepted . Could you please kindly inform us some feedback about what was going wrong and what else we need to do? So that we can know where to focus. We appreciate any help, thank you!!
Hi Thanks for reaching out and creating a pull request. For reasons of sanity, we can't accept PRs from forks that organizations maintain. You should make a PR from your own personal GitHub account. You can collaborate with others and have commits made by multiple people, but one person needs to create the PR, and then others may push to the same PR should they wish. It is OK if you want to use the draft mode while collaborating. The person making the PR is responsible for ensuring the checklist is followed, tests are working, and so on. You can also commit on someone's behalf. See: Also, please create good, small, and succinct commit messages and PR titles. Keep your commits clean and avoid any merge commits unless you have conflicts to resolve. The final PR should not have dirty commits from collaborating on an organization fork like the previous PR.