Jira label proposal: codestyle

Hello!

Context

I noticed some front-end files (css, less and js mostly) have been behind our codestyle practices for a long time. E.g. usersandgroups.css. From what I understand, the way we apply codestyle rules retroactively so far is: 1. solving this ticket needs that I update an old file 2. I make sure the code I update complies to codestyle (eventually 3. I make sure the whole file is compliant to codestyle).

Problem

Personally, I rarely go to step 3 and update codestyle only where I make changes. Most of the time, updating the whole file to respect codestyle takes time and adds complexity to a solution that can far outweight the scope of the initial ticket from step 1. . In the end, those files are rarely fixed because step 2. is good only for features that are being actively worked on.

I would like to be able to keep track of such files that would badly need an update but for which the update is too heavy to add on top of the changes for another ticket. They would make for nice issues to tackle on special days in my opinion.

Proposal

I propose to introduce a new Jira label codestyle. This label would be used exclusively for tickets asssociated to the Development Issues Only component.

Conclusion

If this new label is approved, I’ll add documentation on how and when to use it in our development practices.

Thank you!
Lucas C.

Note that based on https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HRule:Don27tcreateunnecessaryissues depending on how complex the changes are you may not even need a JIRA issue. I mean, I wouldn’t create a JIRA issue just for fixing code formatting (e.g. indentation), or replacing var with let or const for instance. For significant refactoring, like replacing usage of Prototype.js with vanilla JavaScript or jQuery I would consider opening a JIRA issue, but also depending on the amount of code changes. So I’m not sure how exactly this codestyle label would be helpful.

Thanks,
Marius

BTW regarding simple jiras, we’re supposed to identify “Paper Cuts”, see https://dev.xwiki.org/xwiki/bin/view/Community/Contributing#HFixingbugsornewFeatures2FImprovements which leads to https://dev.xwiki.org/xwiki/bin/view/Main/PaperCut The idea is to mark simple issues that can be done for onboarding for example, with difficulty = Trivial. I see that you’ve created several issues with this difficulty.

AFAIU, Lucas’ idea is for when he doesn’t have the time work on refactoring something to apply some best practice/coding style but wants to remember it for later. I think it makes sense.

I think I’d prefer a refactoring label which I find more generic. Refactoring = impl change without changing any API.

In any case +0.

Thanks

+0 for a refactoring label.

Closing this proposal without a change as it seems like it’s not a good idea, and after consideration even a refactoring label would not be very useful.

Thank you for your feedback!

Lucas C.