willkg / ernest Goto Github PK

Would be nice to have a field that can hold PTOs for that week and other important information

Two ideas:

1. put a star next to your name when you're logged in and the bug is assigned to you
2. have a show-only-assigned-to-me button

This might be related to the "starred items" issue #22.

When you log in, the data you were looking at is no longer correct data for your Bugzilla account. For example, if you have permissions to see security bugs, those bugs won't suddenly show up when you log in, but they should.

Possible fixes:

1. after logging in successfully, refresh all the bug data
2. after logging in successfully, add a big hard-to-miss persistent notice at the top of the page that says something like, "You should refresh this page in your browser to get all the bugs"

The project model needs a url field that points to the page describing the sprint process. This should be shown on the project details page. Maybe show it on the sprint details page, too.

That way it's less likely people don't know about the codified process and this will reduce the confusion that results.

The bug details page doesn't say anything about whether a bug is marked secure or confidential. It should. Maybe have the whole page PINK!

Currently, we show the BLOCKED label if the bug has a non-empty depends_on field. That's wrong.

What we need to do is do a fetch_bugs call, get all the bugs for the sprint, go through all those bugs and figure out the set of bugs in the depends_on fields that aren't in the sprint, and then call fetch_bugs on those. Then we build the list of open bugs and we show the BLOCKED label if there are open bugs in the depends_on field.

This means we go from one fetch_bugs call to at most two. I'm pretty sure we can do a fetch_bugs with a list of ids so it should be faster than doing it with filters.

Input bugs don't change much, so it doesn't help Input to have an auto-refresh of the sprint I'm looking at every x minutes. However, SUMO changes a lot and it's annoying to have to press the refresh button all the time.

Thus, we should add an auto-refresh. I think it should have the following requirements:

• sprint details page has an enable/disable button for auto-refresh
• if enabled, the the bug and github data will update every 30 minutes

If we find out that 30 minutes isn't a good one-size-fits-all-value, we can make it a user setting (need to grow user settings first).

For sanity reasons, it's important to display the git sha of the version of Ernest that's "in production". It used to show up in the footer, but doesn't seem to be there anymore.

This issue covers re-adding it to the footer.

The project sprint view really should be a bare template which has JS that does an API call to pull all the bug data for that project for that sprint.

Right now, we pull all the bug data, then dump it in the template in Jinja.

We have like one test. That sucks mostly because it means things break when we refactor stuff.

It's showing a python array right now http://cl.ly/image/0u0P2s0G350J

Probably would be best to show the bug title.

It's nice to know which bugs have open PRs.

We can't figure this out from the bugzilla data since we won't be able to determine whether a bug required multiple PRs or whether PRs got rejected very well.

Thus I think we need to check github for the list of open PRs and use that.

We could use this to pull the data if we implement this server-side:

https://github.com/sigmavirus24/github3.py

We could use this to pull the data if we implement it client-side:

https://github.com/michael/github

(I didn't look very hard at libraries. No clue if there are better options.)

The needsinfo flag needs to show the needsinfo data.

Possibilities:

• on hover, show the list of people who are flagged for needsinfo
• show the information somewhere else
• some third option?

The project details page shows a list of sprints for that project.

It should also show the list of open trackers for that project ordered by target milestone and then priority.

A tracker bug represents a task that is large and has multiple parts each of which represented by a separate bug. Clicking on a tracker bug from the project details page shows the tracker bug details which will show us everything about that tracker that's interesting from a planning perspective as well as a "where is this task at?" perspective.

Having a list of open trackers will give us a 50' view on tasks that span multiple sprints and are probably scheduled on a quarter-by-quarter basis.

Some bugs are secure or confidential, but this isn't noted on the project details page in the tracker bug list.

Bugs that have no estimates should be more obvious. Right now it's subtle that they have no estimate--they're lacking points in the points column. Instead, we should have the row show up light red or have some kind of red label in the points column or something like that.

When you log into Ernest, it turns around and logs you into Bugzilla. It keeps the Bugzilla token in cache and gives you an Ernest session cookie.

It's possible for the Bugzilla token to expire or go away. In this instance, your Ernest session cookie should also expire/go away.

This is most easily reproducible when using simple cache. If you run ernest, log into bugzilla, kill ernest, then re-run ernest, then ernest has forgotten your bugzilla token, but you still have a login cookie.

This should get fixed.

We need to be able to sort by column in the project sprint view.

Further, it should remember how you had that project sprint view sorted last time.

The project sprint view needs to show the priority for each bug.

This issue is defined as "do whatever it takes to make @rehandalal think something other than, 'BOOTSTRAP IS THE WORST.'"

It currently uses the favicon for Fredrik projects (I used Fredrik to generate the basic Flask structure). It needs its own.

Right now the hide/show closed bugs filter button works by switching arrays around under the hood. When I implemented that, I broke one of the tests.

(ernest) (M=ab880 recycle.sh run_tests.sh) saturn2 ~/mozilla/ernest> ./run_tests.sh 
.
----------------------------------------------------------------------
Ran 1 test in 0.170s

OK
INFO [karma]: Karma v0.10.2 server started at http://localhost:9876/
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.2 (Linux)]: Connected on socket lpRP21a4HPV3QN-slgom
PhantomJS 1.9.2 (Linux) ernest controllers SprintDetailCtrl should emit loading events FAILED
    TypeError: 'undefined' is not an object (evaluating 'data.bugs.filter')
        at /home/willkg/mozilla/ernest/ernest/static/js/controllers.js:140
        at /home/willkg/mozilla/ernest/ernest/static/js/test/controllersSpec.js:19
PhantomJS 1.9.2 (Linux): Executed 23 of 23 (1 FAILED) (0.213 secs / NaN secs)

Mike posited that the way I implemented it wasn't the angular way.

This issue covers learning more about angular and either reimplementing it in a more angular-y way or just fixing the test or throwing everything away and rewriting it in Rust or hy or something.

Currently, the name of a project in Ernest must exactly match the product name in Bugzilla. If you enter in a project name that's different, then Ernest flips out when trying to retrieve stuff from bugzilla and you get errors like:

ValueError: max() arg is an empty sequence

This issue covers fixing any of the minor problems in this issue so that this doesn't happen.

We should be able to sort the bug list by the headers (at least priority, status and points)

When looking at what's left in the sprint or what to work on next, it'd be good to have the open bugs separate from the closed bugs.

Maybe we should add a view of the sprint that shows the open bugs in a table at the top and the closed bugs in a table below that? Or maybe (more simply) a view that only shows open bugs?

Right now the project sprint view is /api/project/<projectslug>/<sprintslug>. The api part is wrong--that should get fixed.

This might get fixed when we fix issue #2.

The project details page should denote the sprints where today's date is in the start/end range of the sprint if the sprint has both a start and end date.

Pretty sure we don't handle bugzilla login errors correctly.

At a minimum, this should get tested and verified. If it's a problem, then we should fix it. (obviously)

Ricky says that the "None" in the points column isn't working right and that it's showing None when the points is 0.

I'm guessing it's a whiteboard parsing error. Needs looking into.

If you have multiple whiteboard flags, they all seem to get put in the same label in the display.

Sprints tend to have a lot of bugs in them and usually I'm interested in a small subset of those bugs at any given time.

I want to be able to specify which bugs I'm interested in and show just those bugs in the sprint.

I think this would require something along these lines:

1. ability to star and unstar bugs in a sprint
2. store the list of starred bug ids locally--localstorage or indexdb
3. ability to switch between "all items" and "starred items"

Flask has "instance folders" which makes configuration a lot easier. We should rework our configuration to use that.

http://flask.pocoo.org/docs/config/#instance-folders

Everything should be sent over ssl.

For some reason, sometimes Gravatars all show up as the G when you're logged in. It happens frequently enough in production that both Ricky and I noticed it.

The DB can track more information about sprints. We should show that information on the project sprint list page.

The sprint view used to show whiteboard flags (e.g. [needsverify]), but doesn't anymore. I think it's something missing in the angular rewrite.

For example, this bug has a [needsverify] flag:

https://bugzilla.mozilla.org/show_bug.cgi?id=899482

And that should show up in this sprint:

http://sumo-ernest.paas.allizom.org/project/support-mozilla-org/2013-21

Now that we have end dates, we can denote bugs that are "in trouble". Each project would need to denote the range of days (as a float, I suppose) that each point represents. Then we can calculate "trouble" as follows:

A bug is "in trouble" if":

1. the number of days left in the sprint is <= the maximum number of days the bug could take
2. the number of days left in the sprint is <= the maximum number of days the bug and blockers could take (we'd need point numbers for blockers, too)

Probably need to denote range of days in hours and treat the end date of the sprint as the end of the end date.

If a bug is "in trouble", we could highlight it as red on the sprint page. I'm not sure what else we could do visually.

Maybe we should have a "yellow" state calculated via the start of the hours range and a "red" state calculated via the end of the hours range?

In the sprint details page, if you have closed bugs hidden, then click on refresh, it will show all the bugs, but the state for the hide/show button is wrong. Thus you have to click it twice to get it to hide bugs again.

Right now closed bugs have a green background and a strikethrough, but the strikethrough makes it harder to read the bugs.

Worth nixing the strikethrough altogether.

EOM

The project details page shows a list of tracker bugs sorted by milestone. That's great, but it should also show the progress on those bugs.

For now, I think "progress" should be calculated as the number of closed bugs vs. total number of blocking bugs for that tracker. We can show a bar: [||||||||||||||||----] 60% done (4/6).

I don't want to worry about blocking trees right now.

The sprint data in the whiteboard shouldn't be required to be in a specific order. The following two things should be equivalent:

p=1 u=contributor c=questions s=2014.5

u=contributor c=questions p=1 s=2014.5

This button might even have a checkbox to toggle auto refresh on it. This could help with #18.

It'd be really handy to have a range estimate of how many developer-days of work is left in the sprint.

• 1 point -> half day
• 2 points -> 1-2 days
• 3 points -> 3-5 days

Ordering sprints by name doesn't work well because we're doing string ordering and sprints with names like "2014.1", "2014.10", "2014.2", etc end up in the wrong order.

We should switch to ordering by start_date.

That would require all sprints to have a start_date which might be annoying, but it's probably the right thing to do.

We should build a very small admin section that allows certain people to create projects, create sprints in those projects, edit projects, edit sprints, etc.

The list of admin can be maintained in settings. Or it can be its own table. We don't have user accounts in Ernest so far, so we can fudge this part for now.

• implement project admins
• create new sprint
• edit sprint
• delete sprint
• implement site admin
• create project

If you're looking at a sprint page and hit the "refresh" button, it first dumps all the data, then does the api thing, then repopulates the sprint with the new data.

Instead, it should wait to dump the data until the api thing is successful and we have data to repopulate with.

After moving ernest to heroku, I don't seem to be able to see bugs I have access to when logged in through ernest.

Login seems valid, so I'm not sure what's going on.