Change:
Is there information on the meaning for the various labels used for the issues. I have been searching and haven't found anything. Some of the labels are not clear (to me): Does test iimprovement mean that the person who submitted the issue should test the change or anyone can test it or...? Should members wait for a help wanted label before attempting a fix for an issue? Maybe something info about the labels could be to the wiki? Thanks.
Account Problem - camper has a problem with his/her FCC account such as login problems, losing progress, profile page is missing some solutions and so on. Beta site - the issue is related to FCC's beta site. bug - confirmed and reproducible bug in FCC's code and not only (for example, in ) . CHROME - the issue can be reproduced only in Google Chrome. Curriculum Request - the issue requests a new challenge, adding more explanation to a challenge and so on. Relates to everything that is requested to be to current curriculum. Device Issue - the issue presents only for a particular device (tablet, smartphone, desktop, etc.). Discussing - the issue is currently on discussion stage. duplicate - the issue is duplicate of another issue and most likely will be closed. Easy - the issue is easy to fix. Feature Request - the issue is a feature request for FCC. For example. ability to bonfires from campers profile page. FireFox - the issue can be reproduced only in Mozilla Firefox. help wanted - owners or issue moderators need campers help to investigate or fix the issue. Hikes - the issue is related to Hikes (they are currently not available in curriculum). IE/EDGE - the issue can be reproduced only in Internet Explorer or Microsoft Edge. Remember that we do not support any of these two browsers. FCC officially supports only Google Chrome. in progress - I think this means that currently someone is making a fix for the issue. question - the issue is just a question. Resolved - the issue is resolved/fixed. Test Improvement - the issue should be fixed with a test improvement, which means that someone needs to fix s. todo - something that needs to be done in future. UX (User eXperience) - in this kind of issues campers share their experience with the issue. Wiki - the issue relates to FCC's GitHub Wiki articles. May be a request to create one. Your issue is such a request so I'll add Wiki label to this issue. wontfix - the issue is not fixable or won't be fixed in near future. An example of such an issue is . OK, I left some labels not described here: Accessibility, blocked, confirmed, critical-path, enhancement, invalid, QA, reactify, ready and sounding. Hopefully and other will help to finish the list.
I'm by no means an authority on the subject, but here are som of the remaining labels with descriptions that I think are somewhat correct, maybe, possibly. Please edit them if I'm wrong. blocked - I believe this is for when an issue should not be worked on, due to waiting on the creator to respond to some question or something. confirmed - I think this was the old QA. Not sure if it's used anymore. citical-path - IIRC this is used with very obvious or site-breaking bugs enhancement - I think this is sort of like Feature Request, possibly more related to improving existing features rather than adding new ones? invalid - Probably an issue with a feature or some code that is no longer on the site? QA - Short for "Quality Assurance". For when a fix has been submitted and it needs to be reviewed before merging. reactify - An issue related to the future reacification of FCC.
Accessibility - This is used for issues that don't necessarily break the site but make it harder to use (like when the tests used to evaluate while you typed and would flicker the whole screen). Also this is relevant to enabling the site to be usable for those who may have vision impairment or disabilities. Blocked - We need more information or the issue is stale. Confirmed - This is used when the issue that has been reported has been verified (it basically says to the issue creator that they have successfully communicated how to replicate the issue) but no one has started working toward a fix. UX Similar to accessibility but it focuses on an issue that leads to a negative user experience. If something is more complicated than it needs to be or it is hard to understand how to use a certain feature then this tag is relevant. Easy - This is used to flag issues that aren't critical but should be easy for a camper to fix for their first couple of PRs. Think of these as the camper gateway to becoming a contributor.
thank you so much for your replies. They are above and beyond what I was expecting. One more question. If an issue has wiki label should a camper write something and submit a pull request or is better to wait for discussion about the topic or a help wanted label?
you are free to open PRs and fix issues. You can create a Wiki article about labels if you want. Don't forget to read and first, thanks.
Great! i know all I need to know. Thanks, again.
I think we should keep this open until a wiki entry is created. This is clearly valuable to have and be up to date.
Probably, could create a wiki entry.
I'm not familiar with the labels and currently without checking (not sure where I can find the info) I would just put the info from here. Should that not be part of ?
no, it should be a separate article.
Agreed, this is only relevant to issue mods and owners. I believe this is the only source for label information that exist at the moment.
Anyone feel free to create the page, no need to ask for permission. On Mon, Sep 21, 2015, 1:38 AM Berkeley Martinez wrote: Rafael Rodríguez Top freelancer @ UpWork
Thought I knew all I needed to know, but after reading some of the comments I'm not sure. I created a Wiki page on labels and was going save it in the Wiki section. Should I save offline and submit a pull request instead?
You can just save directly to the wiki
I used the definitions above for a issue labels wiki. However, I do not have descriptions for the following labels: Invalid Reactify Ready Sounding (label: Critical-Path) What is IIRC? Thanks
invalid - Not sure whats up with this Reactify - Issues related to moving to reactjs Sounding - no idea Critical Path - This is no longer used
I think IIRC is short for "If I Remember Correctly". should we remove invalid, Sounding and Critical Path labels if they are not used?
I think it is safe to remove them if they are not currently being used. Do remember that some of these labels (blocked, confirmed, QA) are also tied to Waffle and are automatically and removed by it (worth mentioning in the article).
I will remove the unused labels and add info about labels tied to waffle. IIRC (lol)
It needs editing (the title especially needs help), but here is the link for the label wiki: maybe the label names in the table should be bold...
While we're on the subject, could someone standardize the capitalization of the labels? Some of them use , other's , and I cringe every time I see .
Besides those tied to Waffle I agree that there should be a standard capitalization. I prefer to keep it all lowercase.
I feel your pain
Can I take the liberty to rename them and possibly add colors to colorless ones and delete unused ones? +1 to lower case.
Yes.
I've lower cased, and in some cases shortened, the names of all labels except and since I think these are related to the Waffle board and I didn't dare to. Do you know if they're fine to edit as well, I also think we could merge and into , possibly merge into or vice versa, and remove the following labels: - - - - Thoughts, anyone? Edit: Also, should we rename to or ?
Do not edit those labels related to Waffle (confirmed, QA, Discussing).
I didn't, there were any other than , , , and ? Any thoughts on the other suggestions?
Closing this issue as is created.

Discussion:
"description": [ "Compare and update inventory stored in a 2d array against a second 2d array of a fresh delivery. Update current inventory item quantity, and if an item cannot be found, add the new item and quantity into the inventory array in alphabetical order." ], <del> "challengeSeed": "function inventory(arr1, arr2) {n    // All inventory must be accounted for or you're fired!rn    return arr1;rn}nn// Example inventory listsrnvar curInv = [rn    [21, 'Bowling Ball'],rn    [2, 'Dirty Sock'],rn    [1, 'Hair pin'],rn    [5, 'Microphone']rn];rnrnvar newInv = [rn    [2, 'Hair Pin'],rn    [3, 'Half-Eaten Apple'],rn    [67, 'Bowling Ball'],rn    [7, 'Toothpaste']rn];rnrninventory(curInv, newInv);", "tests": [ "expect(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair pin'], [5, 'Microphone']], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']])).to.be.a('array');", "assert.equal(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair pin'], [5, 'Microphone']], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]).length, 6);", "assert.deepEqual(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair pin'], [5, 'Microphone']], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]), [[88, 'Bowling Ball'], [2, 'Dirty Sock'], [3, 'Hair pin'], [3, 'Half-Eaten Apple'], [5, 'Microphone'], [7, 'Toothpaste']]);", "assert.deepEqual(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair pin'], [5, 'Microphone']], []), [[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair pin'], [5, 'Microphone']]);", "assert.deepEqual(inventory([], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]), [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]);", "assert.deepEqual(inventory([[0, 'Bowling Ball'], [0, 'Dirty Sock'], [0, 'Hair pin'], [0, 'Microphone']], [[1, 'Hair Pin'], [1, 'Half-Eaten Apple'], [1, 'Bowling Ball'], [1, 'Toothpaste']]), [[1, 'Bowling Ball'], [1, 'Dirty Sock'], [1, 'Hair pin'], [1, 'Half-Eaten Apple'], [1, 'Microphone'], [1, 'Toothpaste']]);" </del> <ins> "challengeSeed": "function inventory(arr1, arr2) {n    // All inventory must be accounted for or you're fired!rn    return arr1;rn}nn// Example inventory listsrnvar curInv = [rn    [21, 'Bowling Ball'],rn    [2, 'Dirty Sock'],rn    [1, 'Hair Pin'],rn    [5, 'Microphone']rn];rnrnvar newInv = [rn    [2, 'Hair Pin'],rn    [3, 'Half-Eaten Apple'],rn    [67, 'Bowling Ball'],rn    [7, 'Toothpaste']rn];rnrninventory(curInv, newInv);", "tests": [ "expect(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair Pin'], [5, 'Microphone']], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']])).to.be.a('array');", "assert.equal(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair Pin'], [5, 'Microphone']], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]).length, 6);", "assert.deepEqual(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair Pin'], [5, 'Microphone']], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]), [[88, 'Bowling Ball'], [2, 'Dirty Sock'], [3, 'Hair Pin'], [3, 'Half-Eaten Apple'], [5, 'Microphone'], [7, 'Toothpaste']]);", "assert.deepEqual(inventory([[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair Pin'], [5, 'Microphone']], []), [[21, 'Bowling Ball'], [2, 'Dirty Sock'], [1, 'Hair Pin'], [5, 'Microphone']]);", "assert.deepEqual(inventory([], [[2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [67, 'Bowling Ball'], [7, 'Toothpaste']]), [[67, 'Bowling Ball'], [2, 'Hair Pin'], [3, 'Half-Eaten Apple'], [7, 'Toothpaste']]);", "assert.deepEqual(inventory([[0, 'Bowling Ball'], [0, 'Dirty Sock'], [0, 'Hair Pin'], [0, 'Microphone']], [[1, 'Hair Pin'], [1, 'Half-Eaten Apple'], [1, 'Bowling Ball'], [1, 'Toothpaste']]), [[1, 'Bowling Ball'], [0, 'Dirty Sock'], [1, 'Hair Pin'], [1, 'Half-Eaten Apple'], [0, 'Microphone'], [1, 'Toothpaste']]);" </ins> ] } ]