Do we need concept of cycles in UI in the long run?

[lightandluck]

I wanted to bring this up because of work @Mr0grog did for user tasking and cycles. For v0 it's nice to have for parity, but going forward, I feel we should discard the notion of cycles. See this discussion with @mayaad. Conversation lasts for about 3 min.

The idea of cycles comes from the constraints of the current process. The scraper pulls down changes in chunks, so the analysts look at them in that way and it works as a simple means to rate limit the number of changes they see so it's not overwhelming.

DB + UI won't have those constraints. DB has a complete record and we can chunk it however we want. And UI can display the results in a non-intimidating way simply by paging them. #64, #81 speak to the first part. And we'll naturally page results in the next iterations. (We may want to add a paging parameter to DB api routes to customize size of paging if that doesn't exist already.)

I feel the correct approach in future iterations would be to show all #65 backlogged changes with most recent or high priority first , paged by some reasonable number (user customizable, 25 as default?), and allow them to filter by dates if they're looking to see if something may have changed during X time period when so-and-so got hired or fired, or whatever the use case.

2nd pass classification also seems to have no use for cycles because the collected results happen over a variety of time periods, so labeling and filtering on content changes is more important than when they happened. Of course, they should be able to see when a change happened no matter what, so not suggesting to get rid of time as data!

@ambergman @trinberg Your input would be valuable here.

[Mr0grog]

since we’ll now have continuous, queryable data, I do agree that we should list a page if it has any backlog of changes before the current analysis timeframe, but I don't think we should show changes after the current analysis timeframe. That is, when the analysis timeframe is July 7-10, the current CSV-based workflow shows only changes detected during that timeframe. In the app, we should show any pages with un-annotated changes before July 10.

I think we do still want to use the end of the analysis timeframe because we always have new changes coming in. I think It's helpful to be able to slice off a chunk of work that you can actually feel “done” with, but there is no “done” if you can analyze a page only to have it show up in your list again a few hours later.

That said, as you and @mayaad noted in the video, there are a lot of other ways to slice this. I'm totally 👍 with trying other approaches. In #78 we also talked about having different tabs/views for “my changes” vs. just browsing changes, the latter of which should definitely allow you to do all kinds of fancy queries.

2nd pass classification also seems to have no use for cycles because the collected results happen over a variety of time periods

Totally agree here. I think 2nd pass work is a very different beast and will probably have a different workflow.

[lightandluck]

Agreed, it makes sense to have a cut-off point so analysts have the feeling of being "done". But the issue of how to mark something as "done", store it in the DB, and display it is still up in the air. Maya and I also spoke briefly about this (4-min). She makes very good points 2 min in about being able to see your work in the current session, but after they're "done", they're not displayed anymore.

Definitely something to bring up in meeting, probably after v0, but I just wanted to flag it before we get too far down the road. This is actually a very interesting discussion for me!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in seven days if no further activity occurs. If it should not be closed, please comment! Thank you for your contributions.

[Mr0grog]

I think this is going to be an important question to revisit, but isn’t high priority right now.