adopt "milestone focus" and decide on first focus

[chadwhitacre]

I've written up a proposal for a way to focus our collective attention so that we can work fast and steady:

https://medium.com/building-gittip/7e898db3ae68

tl;dr We should agree on a single Gittip-wide development focus, with a GitHub milestone to manage it.

[chadwhitacre]

IRC re: infinite milestones.

[chadwhitacre]

[W]hat about when the milestone is closed? What about feature creep in that single milestone?

https://botbot.me/freenode/gittip/msg/6139402/

[chadwhitacre]

The conversation I want to have is about what the parts of Gittip are and which sucks the worst.

https://botbot.me/freenode/gittip/msg/6141814/

[zbynekwinkler]

https://botbot.me/freenode/gittip/msg/6142566/

1. Should we adopt the proposal in Milestone Focus for how to focus (using a single milestone)?
   • Let's try it. We sure need some way to focus better. We can always improve the process as we go.
2. If so, what should our first focus be (I proposed Infrastructure)?
   • As a newbie here I welcome the focus on infrastruction (tooling, testing, developer docs, refactoring, build and deployment). It would have had made my life easier starting here, if gittip was better in this area. It will help others to start and in turn build the team @whit537 is mentioning in Team Gittip

[chadwhitacre]

Thanks @zwn. Also:

+1 from @unbracketed: https://botbot.me/freenode/gittip/msg/6139357/
+1 from @mvdkleijn: https://botbot.me/freenode/gittip/msg/6143322/
+1 from @daxter: https://botbot.me/freenode/gittip/msg/6143553/

I'd like to hear from @rummik @duckinator @pjz @wyze, at the least, and @deltab if you're listening.

[zbynekwinkler]

What about bug fixing and maintaining what's already implemented? Like #148, #921, #642 (breaks gittip everywhere) etc.

[rummik]

@zwn That's kind of why I've been suggesting the multiple milestone thing, so we can have some form of a scheduled release cycle that's well planned, with every non-discussion issue falling into a future milestone. But right now I'm just glad we're heading in the direction of having some kind of a milestone to reach.

I'll probably keep pushing for more than one though -- if for no other reason than it means that we can put every accepted issue into the milestone plan (and GitHub can reward us by showing us that there are no open issues that aren't in a milestone :P) I'm going to have to stop focusing on that though.

[zbynekwinkler]

@rummik I think we can work with one milestone. I can imagine using labels to mark issues we didn't want to close with a "focus area" so we can lift them up into a newly started milestone. This way we can keep track of what is the next most problematic part of gittip. Planning to far into the future is guessing (or dreaming), as they say in Rework from 37signals.

As for the maintaining and bug fixing - I'd suggest to maintain and bugfix what we have no matter what's the current focus area. What's implemented needs to work as best as possible, IMHO.

[chadwhitacre]

@zwn I would generally expect to address issues like the ones you mentioned when we explicitly focus on an area they fall under. The app is basically riddled with bugs. Yes, my impulse when I see a bug is to try to fix it immediately. The goal with this whole "focus" initiative is to discipline ourselves about which bugs we allow to capture our attention. The idea is that we'll have better throughput overall if we can avoid chasing every shiny ball that rolls by.

So for Infrastructure, for example, bugs that we introduce during a refactor (e.g., all the regressions from #1320; #1461 is the big one right now) would be fair game. And it'd be fine to fix bugs as a side-effect of a refactor. But we shouldn't get distracted by pre-existing bugs. We'll get to them in due course if we stay focused!

[chadwhitacre]

I'll mention that @rummik gave me the nod on this plan in a private IRC convo.

[chadwhitacre]

As for the maintaining and bug fixing - I'd suggest to maintain and bugfix what we have no matter what's the current focus area. What's implemented needs to work as best as possible, IMHO.

@zwn We have such limited resources that I think for now we should try all focusing on the same area. When we come up for air after a milestone we can look at the app and pick the part where we have the most bugs and problems to work on next.

Maybe we want to switch every month or six weeks instead of every three or four months so we don't go too long without hitting a given area.

One way to conceptualize this is the Golden Gate Bridge getting painted continuously: the work crew starts from one end, moves to the other, and then does it again. I think the cycle is, like, two years, or something?

[duckinator]

I think this is worth a shot. This idea can be tried without any problems tearing it down if it doesn't work out (it should be trivial to remove all issues from a milestone, which would then close it).

On top of the milestone, I'd suggest at least one label that indicates something is high-priority despite being out-of-focus -- an example of something that'd fall under this label would be any security-related issues or things that completely break the site. That allows us to have a method to keep track of them, but we won't have a second milestone endlessly popping in and out of existence (which would be confusing, and probably rather annoying, as well).

+1, on the condition that we a revisit it a month after starting using this approach to see if we like where it's going and/or want to make any tweaks to it. :)

[duckinator]

I'd also propose ~4 week periods for each theme, with 1-2 weeks for general maintenance/bug fixes between them.

[chadwhitacre]

On top of the milestone, I'd suggest at least one label that indicates something is high-priority despite being out-of-focus -- an example of something that'd fall under this label would be any security-related issues or things that completely break the site.

Agreed. Let's pick up w/ labels over on #1230.

I'd also propose ~4 week periods for each theme, with 1-2 weeks for general maintenance/bug fixes between them.

Hmmm ... maybe. Let's get into the first one and see where it takes us?

[chadwhitacre]

i want to hear from @wyze and maybe @pjz and maybe maybe @deltab. If'n @wyze is okay with this proposal then I'm calling it good and moving forward.

[duckinator]

Agreed, let's just see where the first one goes.

[chadwhitacre]

@duckinator I did look up "agile development theme." That's pretty much what we're talking about here with "focus," thanks for the (soft) pointer. I like the word "focus" because it gives us stronger ways to say that something is "out of focus" (what would we say with theme, that something is "off theme"?) or "in focus." Focus implies an in and an out in a much stronger way than theme does, in other words, and I like that.

[wyze]

@zwn That's kind of why I've been suggesting the multiple milestone thing, so we can have some form of a scheduled release cycle that's well planned, with every non-discussion issue falling into a future milestone.

So, my thoughts on the above is the way I would see multiple milestones work in @whit537's vision, would be not to tie a date to milestone completion. I know he was really pushing back on the dates. So while multiple milestones may work for us, the "schedule" would be: once we complete milestone X, we can start milestone Y;

Overall, I like the idea of milestones (foci) as it gives us more of a goal to shoot for rather then a ticket at a time. Seeing the bar become more full, I think would push us contributors to work harder and better (no regressions) to get that bar full.

Infrastructure is a good focus to start with. We boost up tests and documentation, it will be easier to get new contributors started and hooked. Make the code cleaner and more comments describing what functions actually do what, then that is even more of a bonus.

@whit537 count me in!

[zbynekwinkler]

As for the "dates for the milestones" thing: I think the current best practices calls for fixed date for the release and varying the scope (what's done within the date is done, lets move on). I do not have a personal experience with this but it seems that is what the big guys decided to do (chromium, firefox, ubuntu). I must admit I am drawn to it personally because it resonates with me with regards to Parkinson's law.

[mvdkleijn]

In an Agile / Scrum setting the period of 4 weeks sounds fine to me. You'd be able to set dates for milestones, each milestone marks the end of an agile development cycle with a deployment to live attached.

This way milestones can be planned ahead of time (since the 4 weeks is a stable time period) and when issues come in, we can move them into the milestone with the appropriate "theme".

If too much work lands in a single 4-week milestone / agile cycle, we move it to another milestone with the same theme. That way, we can repeat themes over time while still having other themes in between.

I'd propose that "bug fixing" is its own theme by the way, with security and "service breaking" bugs the sole exceptions.

Then again, I'm not an active developer (yet?) so perhaps my vote is less important... 👅

[chadwhitacre]

@wyze Just to be clear, we're going to try not having multiple milestones at once in GitHub. The plan is to have a single milestone in GitHub at a time. When we finish one we'll move to the next.

I think the current best practices calls for fixed date for the release and varying the scope

Well, but we're still going to be releasing continually. Firefox etc. don't make new releases several times a day.

If too much work lands in a single 4-week milestone / agile cycle, we move it to another milestone with the same theme. That way, we can repeat themes over time while still having other themes in between.

Let's keep that option in the back of our collective head. I'd like to try really and truly finishing an area before moving on. It's so satisfying to really finish something!

I must admit I am drawn to it personally because it resonates with me with regards to Parkinson's law.

I guess I have this expectation that if we don't forcefully time-cap our milestone and just let it run it's course, that it will run a course. It won't expand forever. There will come a point at which we have surfaced all of the infrastructure issues that exist right now. The rate of new tickets being added to Infrastructure will decelerate and any new issues being added will be clearly non-issues that we can close.

It's kind of like conversations. In my experience conversations tend to run a natural course, and (totally anecdotally here) I find that there are natural harmonics at 22, 45, and 90 minutes. My hypothesis is that a similar pattern will emerge with milestones, though I could definitely be out to lunch. Let's find out! :-)

[chadwhitacre]

Okay! Let's do this!

I've created an Infrastructure milestone and I've started adding tickets to it. Let's all comb the issue tracker for relevant tickets and add them to the milestone, and let's brainstorm new tickets as well. Huzzah! 👯

[zbynekwinkler]

@whit537 Shall we just assign the milestone directly or do we add some label to propose adding to the current milestone? I've added few issues to the milestone but there seems to be no record of me doing it. This way it will be hard to separate the issues already accepted to the milestone from the ones just proposed. Bugzillans use labels with question marks at the end to propose something.

[chadwhitacre]

@zwn Assign the milestone directly, please. The intention is for the definition of the milestone to be clear enough that each of us is empowered to make the call about what is in focus or not. If there's a dispute let's address that if/when it arises.

[wyze]

@wyze Just to be clear, we're going to try not having multiple milestones at once in GitHub. The plan is to have a single milestone in GitHub at a time. When we finish one we'll move to the next.

@whit537 I know that is what you were shooting for. I was just mentioning that if we happen to have multiple, that is how I saw it working from your standpoint.

[chadwhitacre]

@wyze Cool. :-)