Freecodecamp: Normalize company/product names

Created on 13 Feb 2019  路  23Comments  路  Source: freeCodeCamp/freeCodeCamp

  • [x] Github -> GitHub #34971
  • [x] Linkedin -> LinkedIn #34972
  • [x] Javascript -> JavaScript #35183
  • [x] Typescript -> TypeScript #35203 #35204 #35205 #35206
  • [x] Jquery, JQuery -> jQuery #35184
  • [ ] ReactJS, React JS -> React
  • [ ] Angular JS, AngularJS -> Angular
  • [ ] Wordpress -> WordPress
  • [ ] NodeJS, NodeJs, Node.JS, Node JS, Node Js -> Node.js
  • [ ] Npm, NPM -> npm
  • [ ] FreeCodeCamp, Free Code Camp -> freeCodeCamp ?

Not sure about Angular and Angular JS, but feel free to contribute with more findings by editing this post.

blocked

Most helpful comment

IMHO we should always, refer to the brand guidelines or styling that is used on their official docs, website etc.

Example: https://reactjs.org/ -> React

React makes it painless to create interactive UIs. Design simple views for each state in your a ...

This removes all ambiguity.

All 23 comments

Before you create a PR to change ReactJS or React JS to React, let's get some consensus with some other collaborators first.

That's why I opened that issue.. not touching the ones that are in doubt.. or needs to be addressed.

IMHO we should always, refer to the brand guidelines or styling that is used on their official docs, website etc.

Example: https://reactjs.org/ -> React

React makes it painless to create interactive UIs. Design simple views for each state in your a ...

This removes all ambiguity.

IMHO we should always, refer to the brand guidelines or styling that is used on their official docs, website etc.

Example: https://reactjs.org/ -> React

React makes it painless to create interactive UIs. Design simple views for each state in your a ...

This removes all ambiguity.

@raisedadead Shall I change all spellings to "React" from other variations as suggested by @lipis and submit in individual PRs with fewer number of files changed so that not many files are changed at a time so as to make merging easy?

Yes please. But you should wait for confirmation from @lipis in case they have already started work on it.

@aravindvnair99 Definitely wait until @lipis responds, because we don't want to have two PRs with duplicates on them. Maybe, the two of you can split the work by each taking a different set of languages. Just communicate with each other to make sure you are both using the same technique to find them all.

@lipis @RandellDawson @raisedadead WordPress is the right spelling and as per the guidelines mentioned here, it should be spelled using proper case.

Meta rules 1 as given on WordPress website for both .com and .org:

Spell WordPress using the proper case. WordPress

@aravindvnair99 Definitely wait until @lipis responds, because we don't want to have two PRs with duplicates on them. Maybe, the two of you can split the work by each taking a different set of languages. Just communicate with each other to make sure you are both using the same technique to find them all.

Yes please. But you should wait for confirmation from @lipis in case they have already started work on it.

@RandellDawson @raisedadead Yes, I'll await a response from @lipis . Would love to help! Thanks for responding. :)

@lipis @RandellDawson @raisedadead Roundup of what I could find regarding the naming guidelines:

  1. Angular and AngularJS

AngularJS was the first version and all successive versions are Angular. So technically and theoretically, both are different. We could make changes only for Angularjs / AngularJs / AngularjS to AngularJS.

Reference links:

  1. WordPress

WordPress is the right spelling and as per the guidelines mentioned here, it should be spelled using proper case, i.e. "W" and "P" capital letters.

Meta rules 1 as given on WordPress website for both .com and .org:

Spell WordPress using the proper case. WordPress

  1. React

React is the right term as used by Facebook everywhere and should be changed from Reactjs / ReactJS / ReactjS.

Reference links:

AngularJS was the first version and all successive versions are Angular. So technically and theoretically, both are different. We could make changes only for Angularjs / AngularJs / AngularjS to AngularJS.

I think this one is going to be tricky, because it is going to be based on context. It could be that an article was written concerning the latest version of Angular, but the author used Angularjs by mistake. It would be wrong to automatically name it AngularJS, because it really should actually be Angular. This means there is no easy regex you can write to replace these easily like React or WordPress. It is my opinion that if the number of Angularjs or AngularJs findings are high that we just wait for individual users to make the corrections as they come across them in the normal reading of the articles. That being said, you are more than welcome to try, but I think your time my be better spent on issues we currently have on GitHub.

Hey guys, I haven't started anything from the ones that don't have PR number next to it.. so feel free to work on them! and maybe it's a good idea to edit the initial comment and write your name next to it, on who is working on what.

React and WordPress are easy, but for Angular I'm not sure what should we do. I'm also not familiar if there are courses for older versions of Angular, if not then we could just drop all the JS references. Also I think it's preferable to have just Angular in all cases, than randomly (and wrongfully) seeing AngularJS. It's all Angular now :)

I also added another tricky one: freeCodeCamp.

screenshot 2019-02-14 at 11 07 51

Added more: npm, Node.js

(I hope it's alright to have consistency)

@raisedadead How large do we want to let this one issue get? There are probably hundreds of other product names which are not consistent throughout the guide and curriculum. If we can narrow it down to the big hitters, then maybe a better approach here is instead of trying to fix all of these in replacement PRs, we have the sweeper.js and Probot add a special label Possible Invalid Product Name to any existing/future PR which happens to find one of these misspelled versions of the words. We could take it a step further and have the script/Bot add a review comment requesting a possible change and reference to the word in question. These would look like the same review request changes we manually do now for other PRs.

We found a line in this file which possible contains an incorrect spelling of a product name. Please see the following line and fix if applicable.
image

Moderators: If you do not agree with the suggestion, please dismiss the request. You can view a list of agreed upon product names in issue #35185.
```
The above message is just a first-pass suggestion.

Doing it in this way, would put the burden on the OP/reviewer to check if named needs to be changed and can simply dismiss the requested changes if not applicable. This would be a good way of dealing with names like 'freeCodeCamp' or 'Angular/AngularJS`.

These kind of replacement PRs, which end up touching so many files, always end up with merge conflicts because of the shear number of PRs we have right now. To get them merged quickly involves having to review many other PRs first as not to cause further merge conflicts on earlier PRs (if we were just to merge these out of order). The longer it takes to review/merge these kind of PRs, the more newer PRs with changes can end up with merge conflicts once we finally do merge this kind of PRs.

An example of a PR which involves a lot of prep reviewing before even getting to reviewing/merge of it is PR #35183. @cmccormack and I have started the task of reviewing 104 earlier PRs which also make changes to the same files. Making it even more complex is, some of the earlier PRs also have multiple PRs which will have to be reviewed first, because they are also replacement PRs.

Question: If it is decided we should do the replacement PRs instead, then can we at least not create the PRs until we get the number of open PRs back down to say less than 500-1000? That way, there would be fewer earlier PRs needing to be reviewed first.

@lipis Cool. I'll take up WordPress then for now. We can take one at a time so as to progress in the most efficient way.

@RandellDawson @raisedadead I would suggest we send few files at a time in one pull request so as to not create serious merge conflicts or have too many open PRs. And these PRs could be merged faster as it's just few spelling changes as opposed to serious code changes.

So, how do I go about? Shall I edit few files at a time? I personally feel that would be better for ease of maintaining and merging. And for ease of tracking, a new label could be made for this.

@aravindvnair99, @lipis Wait until @raisedadead responds back to my last comment, because we may not do any more of these bulk "replacement" PRs.

After speaking with @raisedadead, we have decided to put this issue on hold and only allow one more set of PRs (1 for each language) to address the cases where Wordpress should be changed to WordPress.

@aravindvnair99 There are 45 files which have Wordpress. They are all Guide articles. You have permission to go ahead and create the necessary PRs, but make sure you make them for each language and indicate which language in the PR title.

The mods will continue to work through the existing open PRs already created (#35183, #35203, #35204, #35206) along with the PRs @aravindvnair99 will create for WordPress, but we will not accept any further PRs like this until the total number of open PRs gets down to around 500.

I will tag each of you when we reach this milestone and then we can discuss the best approach from there.

ATTN Moderators: Please do not close this issue as we do not want to lose track of this issue. We will tackle it again when the number of open PRs is below 500.

Thank you for all your work and patience regarding this issue.

@RandellDawson the idea of making the bot is pretty nice one and I guess not hard to make and we don't have to update all the changes before installing it, it can be done from now on for all upcoming results. The main reason is that if it's not automated we will have to do these changes once in a while to keep it consistent.

@lipis I agree. The long term plan is to get the bot to do something like I proposed above. The short term plan is to wait until we get down to below 500 open PRs and then do a mass update on some of these others.

I agree with @RandellDawson on this. While we are very interested in making things more consistent, it should not come at the cost of clogging things up. We should do this two steps:

  • Automated linting as proposed in the bot/scripts/tests.
  • Making large sweeps in PRs once we reach a manageable no of open PRs.

This way, everyone wins and we have lesser chore like work to do.

@raisedadead @RandellDawson Should we block this issue further till we have less PRs?

@raisedadead Should we close this issue now?

Was this page helpful?
0 / 5 - 0 ratings