In fact, the client has helpfully indicated that certain browsers and devices should take precedence over others, and they’ve shared that list with your team. So you know that browser and device testing is going to be important. So, how do we make communicating around proposed code changes more clear? As project maintainers, we can provide guidelines for contributors about our expectations and be sure that those guidelines are seen every single time someone proposes a code change.įor example, let’s say that your team is hard at work on a new web app that should look great and work well on a number of different devices and browsers. And having a standard way of doing things-especially a documented, standard way of doing things-is a great step forward to helping your team communicate more clearly. But unless I’ve documented them somewhere, those expectations are probably more of a “nice-to-have” rather than something that will be an accepted standard practice for a project. I could communicate these expectations in many different ways. And as a project maintainer, I want those who propose code changes to explain their changes and let me know me how to test the code. When I propose a change or addition to a codebase as a project contributor, I want the team members who review the code to understand what I was trying to achieve with that work. One of the most critical roles we play as developers is to clearly communicate with our team.
0 Comments
Leave a Reply. |