I was recently tasked with rewriting the base CSS for an inventory/project management system, creating a set of reusable components designed to match, using an open/close approach. These were based on a pretty strict specification provided by one of our designers, who unfortunately left.

The implementation went well, but I’ve run into a bit of a problem. Quite often the team members make changes directly to the base class in the new base CSS file, rather than extending it, creating a new one, or using each system area’s dedicated stylesheet file.

One of the more recent changes involved removing a grid-gap property from a rule from the base CSS, affecting a lot more than the single UI element the team member was working on.

Should I approach the team about this?

I haven’t mentioned anything yet, but have noticed our QA team putting in more bugs about UI elements looking odd

  • jjjalljs@ttrpg.network
    link
    fedilink
    arrow-up
    25
    ·
    10 months ago

    That sounds like a pretty straight forward and simple conversation.

    Do you do code reviews? Have code owners? If you (or a set of people you trust) were required to sign off on changes on the base files that aren’t supposed to be changed willy-nilly, you could catch it before it went to main

      • fidodo@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        ·
        10 months ago

        It’s the best way to propagate coding culture.

        Step 1: Get buy in. Discuss with the team and agree that it’s a good idea. Write it down so there’s a paper trail. Link to it in important base files in comments as a reminder as to what the guidelines are.

        Step 2: Code review. Make sure the right people are required on code reviews for those base files. As the issues are brought up and fixed it will become a cultural habit and self propagate.