Skip to content
This repository has been archived by the owner on Nov 16, 2022. It is now read-only.

let's talk about process #163

Closed
chadwhitacre opened this issue Mar 30, 2015 · 42 comments
Closed

let's talk about process #163

chadwhitacre opened this issue Mar 30, 2015 · 42 comments

Comments

@chadwhitacre
Copy link
Contributor

Alright, stream of consciousness GO. 🐎

@chadwhitacre
Copy link
Contributor Author

I'm looking at http://inside.gratipay.com/big-picture/product and thinking about our development process. I want an excellent product. I want something I'm proud of. That's my goal. My goal is, together with you, to build something that I am proud of. I want you to be proud of it, too! 🏆

@chadwhitacre
Copy link
Contributor Author

The past couple months I've been onboarding people onto GitHub—non-geeks, as part of https://github.com/ambridge/ambridge/. I want to feel good enough about Gratipay to do the same thing. That's my growth plan (#89). Not blog posts. Not social media. I want to talk to normal people IRL:

"What do you do?"
"Gratipay!"
"What's that?"
"Blah blah blah"
"Cool."
"Have your phone? Want to get set up?"

Right now we fail right here. "Pull out your phone. Go to Gratipay.com" See this:

screen shot 2015-03-30 at 12 46 41 pm

Just ... embarrassing. Shoddy. Totally amateur hour. :-(

Scroll down, more suck:

screen shot 2015-03-30 at 12 46 58 pm

😞

@chadwhitacre
Copy link
Contributor Author

I mean, we're just goddam amateurs. We're a mess. Our product is a disgrace. 🍧

@chadwhitacre
Copy link
Contributor Author

The group's most important creation is not the perfect software they write — it's the process they invented that writes the perfect software.

It's the process that allows them to live normal lives, to set deadlines they actually meet, to stay on budget, to deliver software that does exactly what it promises.

https://www.fastcompany.com/28121/they-write-right-stuff

@chadwhitacre
Copy link
Contributor Author

The shuttle group's process is ultimate waterfall. Our process is not their process. But the meta concern, I buy: to deliver an excellent product, we need an excellent process. We're not delivering an excellent product, therefore we need to improve our process.

Take those screenshots above.

Wrong (what we've been doing):

"These screenshots suck."
"Okay! Let's make a ticket, 'homepage sucks on mobile', or 'homepage logo gets cut off on mobile'"

Right (what we need to start doing):

"These screenshots suck."
"What process failure led to homepage mobile suck?"
"Okay! Let's make a ticket: 'process is broken in XYZ way'"

@chadwhitacre
Copy link
Contributor Author

I have hope. The other day I convinced Gitter to join, and I found out they joined when I got an email notification about it! Yay! 💃

I loved seeing that email. It made me feel like we have a real product.

@chadwhitacre
Copy link
Contributor Author

IRC

@chadwhitacre
Copy link
Contributor Author

Upshot of IRC discussion with @rohitpaulk is that we're going to keep the focus on our PR pipeline.

One pattern that seems to be emerging: I touch PRs at the beginning and end of the pipeline. That is, I start PRs on a certain course, and double-check them at the end, while giving @rohitpaulk @Changaco et al. creative freedom in the middle for implementation.

When I start a PR I'll try to explain my intentions, probably in terms of Product and other IA big picture pages.

Can you work with that, @Changaco et al.?

@chadwhitacre
Copy link
Contributor Author

With that, I've abandoned the sprint experiment in favor of a continued and deepening focus on our PR queue.

@chadwhitacre
Copy link
Contributor Author

I propose we abandon the Stalled workflow state. We should only have two PR states: WIP and Review. If something stalls out let's close it. We can always reopen to un-stall.

Objections?

@chadwhitacre
Copy link
Contributor Author

I propose we abandon the Backlog and Ready to Start workflow states. Any issue that isn't Blocked is ready to start. As it is, the Backlog and Ready to Start labels are arbitrarily applied.

@chadwhitacre
Copy link
Contributor Author

Has anyone been using Huboard? I propose we close our account there.

@chadwhitacre
Copy link
Contributor Author

We should only have two PR states: WIP and Review.

In fact, by getting rid of Stalled, we can pare down to a single PR label: Review. Any PR that's not labeled Review is a work in progress.

@chadwhitacre
Copy link
Contributor Author

Also: I'm going to spend even less time on the backend. I'm going to spend my time on information architecture and visual design. Wish me luck. :-)

@chadwhitacre
Copy link
Contributor Author

Instead of sprint milestones I'm looking at using assignments. I know @Changaco uses this.

@chadwhitacre chadwhitacre self-assigned this Mar 30, 2015
@chadwhitacre
Copy link
Contributor Author

I'm going to try to keep a single TODO list in the description for each PR, rather than scattering TODOs about in comments. Hopefully this helps with visibility into PR state.

@chadwhitacre
Copy link
Contributor Author

I want more visibility into and communication about what work everyone is prioritizing and why. Anyone share this itch?

That's really the point of weekly sprints. Milestones are an obvious solution, but sprint milestones conflict with how we're currently using milestones (see gratipay/gratipay.com#67 (comment)). We could accomplish the same goal with a "sprint" ticket at the beginning of every week.

If we don't want to centralize the conversation about priority in a milestone or ticket, we could have priority discussions decentralized among tickets. The PR queue encodes what we're prioritizing, as do assignments (helpful for non-PR work). Comments on assigned issues and PRs could then work to communicate why.

I think it'd be helpful to have a central conversation about priority, though, to make it easier to compare across tickets.

I want to know what you're prioritizing this week and why. Anyone else?

@chadwhitacre chadwhitacre mentioned this issue Mar 30, 2015
@Changaco
Copy link
Contributor

Can you work with that, @Changaco et al.?

I'm not sure I like the idea of people starting PRs that they have no intention of finishing.

I propose we abandon the Stalled workflow state. We should only have two PR states: WIP and Review. If something stalls out let's close it. We can always reopen to un-stall.

Closing sends the PR into oblivion, it seems unlikely that someone would remember to reopen it.

I propose we abandon the Backlog and Ready to Start workflow states. Any issue that isn't Blocked is ready to start. As it is, the Backlog and Ready to Start labels are arbitrarily applied.

We don't really use Backlog, so +1 to drop it. However I'm not in favor of abandoning Ready to Start. An issue that doesn't fit into the other labels isn't necessarily ready to start, for example it may require more discussion before proceeding.

@chadwhitacre
Copy link
Contributor Author

Whatever we decide about labels, let's adopt the same across all (relevant) repos. I've been wanting queues that span our projects (cf. #157), and it turns out that GitHub enables this with their global issue search. Here's all open PRs across all Gratipay repos.

@chadwhitacre
Copy link
Contributor Author

However I'm not in favor of abandoning Ready to Start.

What's the difference between "Ready to Start" and "not Blocked"? And when have we ever required more discussion before diving into coding? :-P

@chadwhitacre
Copy link
Contributor Author

I'm not sure I like the idea of people starting PRs that they have no intention of finishing.

@Changaco I would love to finish the PRs I start, but I have no time. :-(

The problem I'm trying to solve is that I do so much toilet-cleaning (security queue, user support, contributor support, finances, queue visibility, etc.) that I feel like I'm losing my ability to influence the direction of the product. I appreciate you for being so productive. Code is influence, and I feel like anymore I have to throw stuff into the pipeline any chance I get in order to have any influence, because I never know when you're going to emerge with a string of awesome PRs that ... it is my delight to review ... and which squeeze out any time I have left to make big PRs of my own. I feel like after all the toilets are clean, I'm left reacting to your work instead of introducing much of my own.

Knowing what's coming down the pike from you and being able to influence the PRs you work on before they land in my lap for review would help me feel not so threatened, hence #164.

P.S. I don't mind cleaning toilets per se, and I know you and @rohitpaulk help with support as well as managing deployment and production errors, etc. I think I clean a lot of toilets around here, but if you think you do too I trust you'll correct me. :)

@chadwhitacre
Copy link
Contributor Author

Closing sends the PR into oblivion, it seems unlikely that someone would remember to reopen it.

We would remember to reopen it, because it would be linked on the issue(s) that it was addressing. When someone revisited the issue, they would see the old PR and this would prompt them to reopen or cherry-pick as appropriate. Others watching or discussing would be able to remind them as well.

@chadwhitacre chadwhitacre removed their assignment Mar 30, 2015
@chadwhitacre
Copy link
Contributor Author

Another angle: I'm trying to figure out how to influence product direction on a monthly/quarterly time scale (gratipay/gratipay.com#3248) without slowing down work done on a daily and weekly scale.

@Changaco
Copy link
Contributor

What's the difference between "Ready to Start" and "not Blocked"?

One of the uses of the Ready to Start label is to help new contributors find issues they can take on. Take a look at the issues not blocked/ready/WIP, would you say that they all belong in Ready to Start?

And when have we ever required more discussion before diving into coding? :-P

At least a few times I think, and some issues can even be entirely about discussing something and not about writing code. A Discussion label may be useful.

@Changaco
Copy link
Contributor

I never know when you're going to emerge with a string of awesome PRs that ... it is my delight to review ... and which squeeze out any time I have left to make big PRs of my own. I feel like after all the toilets are clean, I'm left reacting to your work instead of introducing much of my own.

Considering that @rohitpaulk has been reviewing bigger PRs and that I was "gone" most of January, I doubt I've been taking up that much of your time this year.

Knowing what's coming down the pike from you

You have at least some idea of what I'm working on, you've linked to it previously, and you could simply ask me on IRC if you want to know more.

being able to influence the PRs you work on before they land in my lap for review would help me feel not so threatened

Threatened?

I know you and @rohitpaulk help with support as well as managing deployment and production errors, etc.

FTR I also manage translations.

I think I clean a lot of toilets around here, but if you think you do too I trust you'll correct me. :)

Can you define "toilet-cleaning" more precisely? Is it everything besides writing code? Is it "boring" stuff in general?

@chadwhitacre
Copy link
Contributor Author

One of the uses of the Ready to Start label is to help new contributors find issues they can take on. Take a look at the issues not blocked/ready/WIP, would you say that they all belong in Ready to Start?

As far as I remember, that was its primary purpose. I don't think it fulfills that purpose well, but let's make that a separate discussion: #166.

@chadwhitacre
Copy link
Contributor Author

At least a few times I think, and some issues can even be entirely about discussing something and not about writing code. A Discussion label may be useful.

I don't think we do this enough to warrant a separate label. The purpose of a label would be to answer questions and filter issues. Have you ever wanted to see all issues that are just a discussion? Or have you ever found an issue listing so cluttered with discussion-only issues that you wanted to exclude them? I haven't.

@chadwhitacre
Copy link
Contributor Author

FTR I also manage translations.

True. !m @Changaco

Can you define "toilet-cleaning" more precisely? Is it everything besides writing code? Is it "boring" stuff in general?

I guess the distinction I'd make is between making progress and avoiding regress, which probably has as much to do with personal motivation as with the task itself. For me, writing code is clearly making progress, while calling the bank to get our Travis charge unstuck is clearly avoiding regress.

Considering that @rohitpaulk has been reviewing bigger PRs and that I was "gone" most of January, I doubt I've been taking up that much of your time this year.

To be honest, I actually had not registered that you were gone most of January (perhaps because I was distracted with the retreat and its aftermath?). And, yes: you and @rohitpaulk seem to be working well together, which is awesome.

!m @Changaco @rohitpaulk

Threatened?

I mean, not threatened threatened, but yeah, vaguely uncomfortable. When you're quiet I don't know if it's because your attention is elsewhere (for how long?), or you're heads-down on a PR. And if it's because you're heads-down on a PR, then what PR is it? Why did you pick that one? And how does it relate to my own goals for Gratipay?

By now I trust your work from a technical perspective. However, to take Gratipay to the next level we need to do a better job of designing our product from the outside in, and that's what I'm trying to do without slowing you down. I think it would help us coordinate the outside-in and inside-out perspectives if we could get a little more communication about what we're working on each week and why.

You have at least some idea of what I'm working on, you've linked to it previously,

Yes, I've noticed that you use assignments to signal what you're interested in working on. However, you hold on to assignments for months, so that doesn't help us know what you're paying attention to this week:

issue assigned ago
gratipay/gratipay.com#1124 Mar 1, 2015 1 month
gratipay/gratipay.com#2487 Feb 28, 2015 1 month
liberapay/postgres.py#26 Feb 28, 2015 1 month
AspenWeb/aspen.py-plugins#9 Feb 18, 2015 1 month
gratipay/gratipay.com#3084 Jan 9, 2015 3 months
gratipay/gratipay.com#1549 Aug 12, 2014 8 months
gratipay/gratipay.com#2390 Aug 12, 2014 8 months

Moreover, assignments alone don't help us collaborate on setting priorities. Why are we each paying attention to the things we're each paying attention to? How do our priorities relate to each other?

and you could simply ask me on IRC if you want to know more.

Fair enough. Can we try an IRC chat every Monday to discuss priorities for the week?

@chadwhitacre
Copy link
Contributor Author

I dropped Backlog, Stalled, and Work in Progress, and made Review orange so it's easier to spot:

screen shot 2015-03-31 at 12 06 33 pm

@chadwhitacre
Copy link
Contributor Author

I'm not sure I like the idea of people starting PRs that they have no intention of finishing.

@rohitpaulk has said he's willing to pick up PRs that I start, so I think we're good there.

@chadwhitacre
Copy link
Contributor Author

Proposal to close this ticket:

  • Weekly IRC chat on Mondays at noon UTC to discuss priorities and tasks for the week.
  • Weekly "radar" ticket to summarize IRC discussion and keep it in view during the week, as well as to allow non-sync people to chime in.

@chadwhitacre
Copy link
Contributor Author

Objections?

@Changaco
Copy link
Contributor

Changaco commented Apr 1, 2015

made Review orange

That color is typically used for warnings and such, maybe switch with the yellow of Security?

@Changaco
Copy link
Contributor

Changaco commented Apr 1, 2015

I guess the distinction I'd make is between making progress and avoiding regress, which probably has as much to do with personal motivation as with the task itself. For me, writing code is clearly making progress, while calling the bank to get our Travis charge unstuck is clearly avoiding regress.

I'd make an additional distinction between writing/modifying "clean" code, and fixing "dirty"/broken code. I've spent a lot of time cleaning up Gratipay's code (plus some time on Aspen's), and while it is often interesting and can be viewed as "making progress", it wouldn't be necessary if things had been done "right" the first time, and thus can occasionally be boring/irritating.

To be honest, I actually had not registered that you were gone most of January

That seems to indicate that I'm not the problem, especially since me not being here didn't result in you landing big PRs of your own.

Why did you pick that one?

We've already had that conversation in the past, there are plenty of possible motives.

By now I trust your work from a technical perspective. However, to take Gratipay to the next level we need to do a better job of designing our product from the outside in, and that's what I'm trying to do without slowing you down.

If by "oustide in" you mean starting with the UI like you did in gratipay/gratipay.com#3112, that seems like a bad idea. If you start with the backend you can split the work in multiple PRs of reasonable sizes, but if you start with the UI you end up with a giant PR.

@chadwhitacre
Copy link
Contributor Author

That color is typically used for warnings and such, maybe switch with the yellow of Security?

Colors tweaked:

screen shot 2015-04-01 at 11 26 01 am

@chadwhitacre
Copy link
Contributor Author

I'm not the problem

Correct. You are not the problem. :-)

Why did you pick that one?

We've already had that conversation in the past, there are plenty of possible motives

I believe you're thinking of IRC, yes?

How do you prioritize which bugs to fix and which features to implement?

I don't really have a precise method to choose, I just do, it can be because there's a bounty on the issue, or lots of +1's, or because it annoys me personally, or because someone else has started the work and needs help to complete it, or�

That answers the question in a general way, but it doesn't answer the question in specific instances. At any given time, why are you focusing on this instead of that? Actually, though, let's flip this around: I want you to know what my goals and motivations are. Why? So that you can help me reach them by critiquing my prioritization decisions.

In other words, maybe the problem is me. ;-)

@chadwhitacre
Copy link
Contributor Author

However, to take Gratipay to the next level we need to do a better job of designing our product from the outside in, and that's what I'm trying to do without slowing you down.

If by "oustide in" you mean starting with the UI like you did in gratipay/gratipay.com#3112, that seems like a bad idea. If you start with the backend you can split the work in multiple PRs of reasonable sizes, but if you start with the UI you end up with a giant PR.

I mean slowing down and spending more time in requirements gathering and implementation design before starting to code. "Design from the outside in, build from the inside out." 3112 is not a paragon of this. gratipay/gratipay.com#3220 is more what I want to do, and that's the tip of the iceberg. I'm planning to use gratipay/gratipay.com#3248 as the focal point for what I want to accomplish in terms of product design, with weekly radar tickets to help me stay on track and communicate with the rest of you, and much better-scoped PRs.

@chadwhitacre
Copy link
Contributor Author

More deliberate. "Here's what we want to deliver. Here are the clearly-defined steps we need to get us there." I'm nervous. I'm bad at working like that. :-(

@webmaven
Copy link

webmaven commented Apr 2, 2015

I'm bad at working like that.

@whit537 I am too. I find that narrowing the scope of the deliverable helps.

@chadwhitacre
Copy link
Contributor Author

We currently have 7 tables referencing username [...] and 5 tables referencing id[.]

@Changaco I am unpleasantly surprised by this, because the last I knew we were going to have a discussion about switching to id for pk. Now I'm learning that we're almost half-way switched, without the discussion ever having taken place.

I appreciate you for not being afraid to "own" Gratipay. We want a shared sense of ownership. Something feels wrong about this, though. What is it? What's wrong with our process that we ended up in this situation?

@Changaco
Copy link
Contributor

Changaco commented Apr 3, 2015

What's wrong with our process that we ended up in this situation?

The first PR to introduce a table that references id was gratipay/gratipay.com#2701: you didn't notice it and I didn't explicitly ask for your approval (I either forgot or assumed it was okay). In later PRs there was no reason for me to ask if it was okay to reference id since we were already doing it.

@chadwhitacre chadwhitacre mentioned this issue Apr 6, 2015
@chadwhitacre chadwhitacre mentioned this issue Apr 13, 2015
@chadwhitacre
Copy link
Contributor Author

I suppose this is now moot in light of @Changaco's departure.

!m @Changaco

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants