Change:
} } <del> function countOnline(usersObj) { </del> <ins> function countOnline(allUsers) { </ins> // Only change code below this line // Only change code above this line

Discussion:
This seed code can lead to a bit of confusion because the global variable name and parameter name are pretty similar What about isn't my favorite if someone has another idea. I just don't like when the type isn't strictly needed. No response All No response
can I work on this if anyone is not working?
This issue isn't ready for PRs yet
One idea for naming: -or -
I went with something other than because 1) that's the example 2) at least one learner has has said was a little hard to grok at first We could change the example (and maybe we should in light of 2?)
I can appreciate the idea behind it but I don't think the names should imply they are different things, and are not the same thing. Wouldn't just changing to for the parameter and leaving the object name as is work?
We can use that as the parameter name; I like it better than . This still doesn't fully handle the user complaint though. I see two problems 1) is a really awkward variable name. Swapping to fixes this. 2) Given the example, its an easy bug for users to write instead of the intended . Not sure if we want to address this or ignore this. Changing the global object name seems to be the best way to address this.
Maybe what really needs to be done is to change the example to something else, like maybe or something like that?
If we change the parameter we should change the example as well. Either to something unrelated and change the text as needed, or it would need to use as well. I think we are, in part, trying to fix the underlying issue of campers not fully understanding parameters and arguments. Which I'm not sure how or where to address. I think the code highlighter isn't helping either. Usually, const and arguments are colored differently from parameters and reassignable variables. As an example (I changed the loop to use const as well) !
Not sure how I feel about the parameter name but it might work.
I like the direction. How about Instructions Sometimes you need to iterate through all the keys within an object. You can use a </dfnloop to do this. The </dfnloop looks like: This code logs and , with each value on its own line.

We defined the variable in the loop head and this variable was set to each of the object's keys on each iteration, resulting in each food's name being printed to the console. We've defined a function which accepts one argument, . Use a </dfnstatement inside this function to loop through the object and return the number of users whose online property is set to . An example of an object which could be passed to is shown below. Each user will have an property set to either or . Seed Code I think this way we use your better parameter name and we swap the example for something that doesn't lead the learner to the bug.
I think it looks good. As an aside, if we are documenting how works we should show how to access the properties on the object (in the example). I know we have taught how to use variables with objects and making them bridge the gap might force the learner to think about it more. But it feels a little wrong to me to teach without actually showing how to use it.
Small tweak for that: Instructions Sometimes you need to iterate through all the keys within an object. You can use a </dfnloop to do this. The </dfnloop looks like: This code logs and , with each key-value pair on its own line. We defined the variable in the loop head and this variable was set to each of the object's keys on each iteration, resulting in each food's name being printed to the console. We've defined a function which accepts one argument, . Use a </dfnstatement inside this function to loop through the object and return the number of users whose online property is set to . An example of an object which could be passed to is shown below. Each user will have an property set to either or . Seed Code