![]() A well-written story including a description of the problem and sample solution. A well-written story makes for clear requirements when it comes time to PR. ![]() A story/issue doesn’t need to be overly complicated, but should be easy to understand. A story should include the requirements of the work and a potential solution (if you have one in mind). This involves creating “stories” (with GitHub issues), representing bite-sized chunks of work. At Sparkbox, we often use ZenHub or GitHub Projects to organize engagements akin to Scrum. To ensure good pull requests, try to write good issues. Here are a few things we do at Sparkbox to improve PR readability for everyone. But what if the other dev isn’t free? What if the other dev lives in another time zone? What if you need a project manager or designer to look at your work who doesn’t have a local setup or much dev experience? Sure, many of us have the luxury of walking to our coworker’s desk and getting a walk through. ![]() If done poorly, PR reviews can mean a few hours of attempting to understand both the problem and the solution, and checking that the result matches the design. Reviewing a pull request can feel like a chore. When developers have new code to add to the project, they ask other developers for a code review via a pull request, or PR. Here at Sparkbox, we store nearly all of our code on GitHub, in shared repositories dedicated to whatever engagement on which we are currently working. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |