5 ms·

Wow I love the idea, thanks for making this and congrats on the launch. From the comments I read I can tell the receiving devs can easily become grumpy if thin

Wow I love the idea, thanks for making this and congrats on the launch. From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon. A few ideas to solve that problem. 1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well. 2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it. Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).

hzia 3y ago
You are totally right about human interface management. For software engineers, that bar is really high as devs by default engage in a ton of tools for their day to day work to convert tickets to PRs And also agree about engineering teams being super nitpicky. We recently rolled out a change to suggest tickets to add linting / formatting tools automatically based on nitpick comments https://gitstart.com/changelog/ticket-suggestions-private-beta https://gitstart.com/changelog/ticket-suggestions-private-be... However, I am very curious about the approach of pushing out process with every PR. Would that come as form of a PR description?
- quadcore 3y ago
  Would that come as form of a PR description? Yes. Always the same though (maybe with some variants you write over time). I think the best might be to guide the receiving party so they act exactly like you want. Example: "Hello nice to meet you. We are a bunch of junior devs learning to make production code. We'd appreciate if you'd read our PR. However, if at first glance it doesnt look at all like something you'd merge, please simply send us a "nope" and we'll figure out why ourselves with the help of our mentors. Our goal is for you not to spend time on totally off-road PRs. However if the PR is interesting to you, please proceed like you always do. You can always reach us via [some form url that's automatically generated for that PR]" Something like that that someone who can write and think has writen. Take control at every step to prevent the receiving party to roam freely with the PR so to speak (unless it's decently good), because they might gonna go left and right - and south otherwise. They'll attack you on superficial thing. Make them a smooth funnel so they dont have to talk to nobody to move forward. That's what came to mind. P.s. or send them a url they follow entirely. 1. Read the PR in 15 min and come back here 2. How do you like it at first glance? A) very much, it's merged already, B) it's okay but I have feedbacks, C) not at all what we need sorry. Etc.
  - hzia 3y ago
    I love this! We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action And build an experience that guides them through the PR instead of getting distracted by nit picks. I we can only go so much with GitHub UX (bar chrome extension), so we may just have to rebuild the entire thing in our dashboard. Currently we include a loom video on every PR (if its a frontend PR) along with a unique link to our dashboard to review / approve credit budgets. But we should double down to give a potentially better PR review experience and take over the experience in the long term
    - quadcore 3y ago
      Amazing. Glad this inspires you. Another idea, maybe your PR is just a hook with no code initially, and then once the process is done via your UI, the final PR is shipped out - or the initial PR is patched. We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action Absolutely, this is an entire experience to rethink. If they love the experience, boom, the way I see it, you made it. Because when you think about it, you are changing things (very) deeply. Everyone ever wanted the backlog to be outsourced. I used to say, "if only we had fucking debugguers" ; to take on those nasty bugs that are essentially just a nuisance for the bottom line of business. However it's gota be a procress for it to work. Brogrammers are just gonna mess the thing up. I was thinking, maybe have a link in the PR for a receiving programmer to take on the PR, and then, use emails to get the programmer in the dashboard at key moments (brainstorming here, can only guess the details of how your thing work). With a dashbard for management (probably you have that already). Think Jira, agile, process, industrialization, linkedin skill, etc. Cause the way I see it, you cant do it if you dont do it with deep integration. Otherwise human will freak out a thousand ways. Maybe have 3 different PRs for one task, the engineer can quickly browse. I know it sounds crazy but you know how this works: work from the customer and backward. Wouldnt you love to have 3 PRs you can browse and say: combine this and that and this and we good. Just throwing ideas out. Really love that startup your working on. It goes beyond what the eye can see. Companies are bad at managing software development, they always were. They dont understand they need engineers - and technicians. They cant tell the difference, they only see programmers. With your stuff, one can imagine a future where they understand that (theyd hire engineers internally, and have technicians outsourced). I dont know. Im dreaming and halucinating at the same time, but seems to me it goes in the right direction.

hzia 3y ago

You are totally right about human interface management. For software engineers, that bar is really high as devs by default engage in a ton of tools for their day to day work to convert tickets to PRs And also agree about engineering teams being super nitpicky. We recently rolled out a change to suggest tickets to add linting / formatting tools automatically based on nitpick comments https://gitstart.com/changelog/ticket-suggestions-private-beta https://gitstart.com/changelog/ticket-suggestions-private-be... However, I am very curious about the approach of pushing out process with every PR. Would that come as form of a PR description?

quadcore 3y ago
Would that come as form of a PR description? Yes. Always the same though (maybe with some variants you write over time). I think the best might be to guide the receiving party so they act exactly like you want. Example: "Hello nice to meet you. We are a bunch of junior devs learning to make production code. We'd appreciate if you'd read our PR. However, if at first glance it doesnt look at all like something you'd merge, please simply send us a "nope" and we'll figure out why ourselves with the help of our mentors. Our goal is for you not to spend time on totally off-road PRs. However if the PR is interesting to you, please proceed like you always do. You can always reach us via [some form url that's automatically generated for that PR]" Something like that that someone who can write and think has writen. Take control at every step to prevent the receiving party to roam freely with the PR so to speak (unless it's decently good), because they might gonna go left and right - and south otherwise. They'll attack you on superficial thing. Make them a smooth funnel so they dont have to talk to nobody to move forward. That's what came to mind. P.s. or send them a url they follow entirely. 1. Read the PR in 15 min and come back here 2. How do you like it at first glance? A) very much, it's merged already, B) it's okay but I have feedbacks, C) not at all what we need sorry. Etc.
- hzia 3y ago
  I love this! We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action And build an experience that guides them through the PR instead of getting distracted by nit picks. I we can only go so much with GitHub UX (bar chrome extension), so we may just have to rebuild the entire thing in our dashboard. Currently we include a loom video on every PR (if its a frontend PR) along with a unique link to our dashboard to review / approve credit budgets. But we should double down to give a potentially better PR review experience and take over the experience in the long term
  - quadcore 3y ago
    Amazing. Glad this inspires you. Another idea, maybe your PR is just a hook with no code initially, and then once the process is done via your UI, the final PR is shipped out - or the initial PR is patched. We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action Absolutely, this is an entire experience to rethink. If they love the experience, boom, the way I see it, you made it. Because when you think about it, you are changing things (very) deeply. Everyone ever wanted the backlog to be outsourced. I used to say, "if only we had fucking debugguers" ; to take on those nasty bugs that are essentially just a nuisance for the bottom line of business. However it's gota be a procress for it to work. Brogrammers are just gonna mess the thing up. I was thinking, maybe have a link in the PR for a receiving programmer to take on the PR, and then, use emails to get the programmer in the dashboard at key moments (brainstorming here, can only guess the details of how your thing work). With a dashbard for management (probably you have that already). Think Jira, agile, process, industrialization, linkedin skill, etc. Cause the way I see it, you cant do it if you dont do it with deep integration. Otherwise human will freak out a thousand ways. Maybe have 3 different PRs for one task, the engineer can quickly browse. I know it sounds crazy but you know how this works: work from the customer and backward. Wouldnt you love to have 3 PRs you can browse and say: combine this and that and this and we good. Just throwing ideas out. Really love that startup your working on. It goes beyond what the eye can see. Companies are bad at managing software development, they always were. They dont understand they need engineers - and technicians. They cant tell the difference, they only see programmers. With your stuff, one can imagine a future where they understand that (theyd hire engineers internally, and have technicians outsourced). I dont know. Im dreaming and halucinating at the same time, but seems to me it goes in the right direction.