Issue tracker usage within a milestone

[zbynekwinkler]

I've just made pass over the issues (most updated first) and I must say it is kind of easy to get lost. The feeling I got is that everything

1. depends on something that is not done
2. which cannot be done by me
3. or I am not sure what it would bring (is it worth my time?)
4. or if it is something to discuss

The only issues the come out for me are most often exceptions from sentry and of those a lot depend on elsewhere that @whit537 is working on right now.

How are others doing? Do we need more labels? Something like blocked, missing info, discussion needed, coder needed - something to let others know what that current issue needs. Otherwise I don't know like you but I'll spend more time combing through than working. And the fact that others are available over the week and me on weekends is not helping either.

[seanlinsley]

I find status labels very useful, as I said in https://github.com/gittip/www.gittip.com/issues/1230#issuecomment-24190733

As well, something like this is great for tracking progress: https://huboard.com/

[zbynekwinkler]

I haven't tried https://huboard.com/ yet but I will tonight (to get the feel, hands on experience). Thanks for reminding. It looks like something that could help me (at least). I'll let you know how it went.

[chadwhitacre]

Per IRC, some thoughts on how to wrangle this Infrastructure milestone ...

I think we need to narrow our focus further, and start dropping issues from Infrastructure. You'll notice that I've already started doing this (#1417 was the first in a spree tonight).

The point of this milestone is "big rocks." Systems! What are the big systemic problems that make Gittip downright dangerous to work on?

• Developer Documentation - The README is overgrown. We need a new, more robust dev doc system. We've barely started on this one, but this might actually be our biggest need.
• Logging - We need a clear understanding of the kinds of logging we need and what tools we're using for each kind of logging. I think we're pretty close on this one.
• Database - We need to understand our schema and the patterns we're using in it, and how to apply them to new work going forward.
• Legal & Finance - We need to make sure we're not screwing up.
• Testing - We need coverage reporting and a system for client-side testing.
• Refactoring - We need a style guide and then we need to apply it. We need a new elsewhere subsystem because it's the WETest part of our codebase.

I propose we take a pass through the issues on Infrastructure and drop anything that isn't a systemic issue, meaning little bugs get dropped, unless they are blocking big systemic changes. Once Infrastructure is done we'll start circling back and going deep on one area at a time, addressing both little bugs and medium-level refactoring driven by user experience needs. Or we may decide that there's enough little bugs to simply focus on those for a while.

[chadwhitacre]

@zwn @rummik @clone1018 Basically it's the three-and-a-half of us working on this Infrastructure milestone. We have to take that into account when defining its scope. The point is to address big systemic issues. Like, "OMG the bridge is half rusted and is about to collapse into the sea." Let's fix the bridge. Let's ignore the cracks in the sidewalk for now.

• My understanding is that the systemic issues that @rummik (and @clone1018) are interested in are things related to JavaScript ... linting, code formatting, testing. That's awesome. (@wyze seemed interested in this as well but seems to be focusing elsewhere for the moment.)
• From @zwn I'm hearing an interest in database and logging issues, understanding and architecting our schema and making sure we have visibility where we need it most. That's awesome.
• Looking through the above list, that leaves me with developer documentation, the legal/financial basis of Gittip, and this elsewhere refactor.

I've started seeing @zwn assign tickets to himself as a way to keep track of his own queue, and I know @rummik and I have discussed the same in the past. Let's go ahead and adopt that practice. Let's have each of us assign tickets to ourselves from the Infrastructure milestone. Let's focus on the rusting bridge (big issues) and ignore the cracks in the sidewalk (small bugs). Once we've done that I'm going to take a pass through the issues and drop anything that doesn't have an owner.

How's that?

[chadwhitacre]

@zwn I keep thinking about this ticket and wanting to talk with you about this. I just went through and assigned 38 tickets to myself. As I was going through I was thinking that there are a number of tickets about the database that you could be working on if we maybe had a clearer picture of how we're using it and where we're headed. So the big blockers for you are:

• elsewhere (#1369)
• database doc (#1272)
• aspen issues

Yes? How are we doing with logging? I just made you an admin on Sentry, so hopefully you have more freedom to maneuver there.

[zbynekwinkler]

@whit537 I mostly agree the two comments above. The biggest blocker for me in the database area is #1549. I have described my preferred way forward in https://github.com/gittip/www.gittip.com/issues/1549#issuecomment-25756162. As it stands now I am finding it hard to find motivation to work on the db because it somehow does not feel right :(.

As for my general preferences - I like simple, healthy, clear, slick, principle-of-least surprise things. Be that python, sql, js, html, general UI of the site - that does not matter that much. I like removing things/code/features that are not that useful (or where maintaining them does not seem worth the effort) and making the rest even more useful, visible, so it is worth the time we spend on it. And of course, I think gittip is going to be the next big thing (tm), so I'd like to help that happen :smile:

[zbynekwinkler]

@whit537 I see neither "oh my god, sky is falling" nor "rusting bridge" issues I could tackle :(. I've assigned a couple smaller ones to myself. I am not sure who else has got enough knowledge of the code base to do anything bigger. Just checking that email thing for balanced #453, took me a while and that does not look like a big deal. I am thinking maybe reviewing PR would be more beneficial?

[chadwhitacre]

Per IRC:

• We're basically good on logging. IRC
• @zwn is going to be in charge of database cleanup (#1549 ff.) IRC
• I'm going to take a pass through the issue tracker and drop smaller issues from Infrastructure. I'll label them temporarily so @zwn @rummik and others have a chance to review my decisions. IRC

[chadwhitacre]

I took a pass through the issue tracker, but, buoyed by our success with logging this past week and @zwn's stepping up to the plate re: the database schema and @rummik's impending 'top delivery, there was nothing more I was ready to cut from the milestone at this point. I did a queue size correction last Friday, so we're back where we were a week ago in terms of total queue size.

Let's guard against adding new issues to Infrastructure and see if we can't put a dent in the existing open issues over the next week or two. Can we close another 15% of issues in two weeks? That would bring us to 50% completion after five weeks, which means we'd be on track to land Infrastructure in December.

[chadwhitacre]

@zwn What else do we need to close this issue?

[chadwhitacre]

Silence == consent. :-)