New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For edit-a-thons (at least), dashboard should give user info about when to expect updated stats #1005

Closed
ragesoss opened this Issue Oct 24, 2016 · 20 comments

Comments

Projects
None yet
4 participants
@ragesoss
Member

ragesoss commented Oct 24, 2016

A common question / point of confusion is why edits aren't showing up yet during edit-a-thons. The dashboard should make it obvious to users that data gets pulled in periodically and it may take a while to show up.

Ideally, it could show actual info about how long the update cycle takes (based on the latest one) and/or when to expect the next update.

@Ladsgroup

This comment has been minimized.

Show comment
Hide comment
@Ladsgroup

Ladsgroup Dec 26, 2016

Contributor

👍

Contributor

Ladsgroup commented Dec 26, 2016

👍

@keer25

This comment has been minimized.

Show comment
Hide comment
@keer25

keer25 Mar 24, 2017

Contributor

Design for displaying the message : How about a info icon that opens a popup message on hovering over it.

Contributor

keer25 commented Mar 24, 2017

Design for displaying the message : How about a info icon that opens a popup message on hovering over it.

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Mar 24, 2017

Member

@keer25 yes, something like that would make sense.

Member

ragesoss commented Mar 24, 2017

@keer25 yes, something like that would make sense.

@keer25

This comment has been minimized.

Show comment
Hide comment
@keer25

keer25 Mar 25, 2017

Contributor

The constant update that happens every 15 minutes pulls revisions and hence except for article views and commons uploads all other metrics get updated every 15mins.? What about articles creates? How often is it updated?

Contributor

keer25 commented Mar 25, 2017

The constant update that happens every 15 minutes pulls revisions and hence except for article views and commons uploads all other metrics get updated every 15mins.? What about articles creates? How often is it updated?

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Mar 25, 2017

Member

ConstantUpdate runs every 15 minutes, but it exits immediately if another instance of that process is already running. Currently, updates are taking about 4 hours each on Wiki Ed production, and 8 hours each on Programs & Events Dashboard. The update process reports the time the update took to the logging service Sentry — see the Raven.capture_message call in BatchUpdateLogging.

One way to handle this could be to also record that update time somewhere else — such as using Rails.cache — and then use that to show the user a) how long each update usually takes, and b) when the last update finished.

Member

ragesoss commented Mar 25, 2017

ConstantUpdate runs every 15 minutes, but it exits immediately if another instance of that process is already running. Currently, updates are taking about 4 hours each on Wiki Ed production, and 8 hours each on Programs & Events Dashboard. The update process reports the time the update took to the logging service Sentry — see the Raven.capture_message call in BatchUpdateLogging.

One way to handle this could be to also record that update time somewhere else — such as using Rails.cache — and then use that to show the user a) how long each update usually takes, and b) when the last update finished.

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Oct 13, 2017

Member

An update on this... Currently, ConstantUpdate updates take about 15 minutes on Wiki Ed production, and about 2 hours on P&E Dashboard. DailyUpdate takes about 1 hours on Wiki Ed, and 4 hours on P&E.

We now have a Setting model which could be used to keep track of update data, such how long each of the last 10 constant and daily updates took and which update started most recently when.

Member

ragesoss commented Oct 13, 2017

An update on this... Currently, ConstantUpdate updates take about 15 minutes on Wiki Ed production, and about 2 hours on P&E Dashboard. DailyUpdate takes about 1 hours on Wiki Ed, and 4 hours on P&E.

We now have a Setting model which could be used to keep track of update data, such how long each of the last 10 constant and daily updates took and which update started most recently when.

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Oct 16, 2017

Contributor

I'm checking this issue for my next contribution, but tbh I think it is to backend-ish for me to properly understand. I have several questions regarding the issue, and I would like to understand them better as it's a relevant topic at the art+feminism program.

  • I was checking the Setting model but I am unable to find the Service table. Why? I mean, is not part of the database yet?
  • What do you mean with using the Setting model in order to keep track of the updated data? Something like creating some methods that are searching for the last updates (e.g. Rails.cache.fetch('Update finished')) and counts the avge time an update needs to finish?
  • About the UI, I thought it could be added to the hover bubble at articles.cross_wiki_tracking. What do you think?

Please let me know if you prefer me to ask you via slack or email.
Thanks!!!

Contributor

mauditecandela commented Oct 16, 2017

I'm checking this issue for my next contribution, but tbh I think it is to backend-ish for me to properly understand. I have several questions regarding the issue, and I would like to understand them better as it's a relevant topic at the art+feminism program.

  • I was checking the Setting model but I am unable to find the Service table. Why? I mean, is not part of the database yet?
  • What do you mean with using the Setting model in order to keep track of the updated data? Something like creating some methods that are searching for the last updates (e.g. Rails.cache.fetch('Update finished')) and counts the avge time an update needs to finish?
  • About the UI, I thought it could be added to the hover bubble at articles.cross_wiki_tracking. What do you think?

Please let me know if you prefer me to ask you via slack or email.
Thanks!!!

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Oct 16, 2017

Member

Either here or slack are best.

There is no Service table. What is that in relation to?

For using the Setting model, I was imagining something like this: a Setting record with a key like data_cycle or recent_updates, with the value being a hash that holds everything we need to give users an idea of how long it should take to update: when each of the last X updates took and how long each took, and when the current update (of which kind) started.

For UI, I think it should at least be accessible from the home tab somewhere, as those stats the first point of entry for users wondering why the dashboard isn't reflecting their work yet.

Member

ragesoss commented Oct 16, 2017

Either here or slack are best.

There is no Service table. What is that in relation to?

For using the Setting model, I was imagining something like this: a Setting record with a key like data_cycle or recent_updates, with the value being a hash that holds everything we need to give users an idea of how long it should take to update: when each of the last X updates took and how long each took, and when the current update (of which kind) started.

For UI, I think it should at least be accessible from the home tab somewhere, as those stats the first point of entry for users wondering why the dashboard isn't reflecting their work yet.

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Oct 17, 2017

Contributor

I meant 'Setting' table, not Service, sorry.

My first thought regarding this (spoiler: basic questions to come):

  1. We could create a last_update method at Settings Model that fetch the last updates and calculates the time left for the next update. Would you add all this information to the ':values' parameter from Settings model?
  2. We could add this last_update method to log_end_of_update method at 'BatchUpdateLogging' so it gets called everytime the update takes place. If not, somewhere else I am not aware of?
  3. How should we test this? Should I just run the dashboard for some time and manually wait for updates?

Please let me know if this fits your proposal or if I am totally lost.
Thanks :)

Contributor

mauditecandela commented Oct 17, 2017

I meant 'Setting' table, not Service, sorry.

My first thought regarding this (spoiler: basic questions to come):

  1. We could create a last_update method at Settings Model that fetch the last updates and calculates the time left for the next update. Would you add all this information to the ':values' parameter from Settings model?
  2. We could add this last_update method to log_end_of_update method at 'BatchUpdateLogging' so it gets called everytime the update takes place. If not, somewhere else I am not aware of?
  3. How should we test this? Should I just run the dashboard for some time and manually wait for updates?

Please let me know if this fits your proposal or if I am totally lost.
Thanks :)

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Oct 17, 2017

Member

The table is called settings, per Rails convention, corresponding to the Setting model.

I don't think we want to cram all this into the Setting model itself, since this behavior would be focused on one particular Setting record. We probably want a new class to handle updating the record (which could be called from relevant places in BatchUpdateLogging methods). Then the class could be tested independently of the update process itself.

Member

ragesoss commented Oct 17, 2017

The table is called settings, per Rails convention, corresponding to the Setting model.

I don't think we want to cram all this into the Setting model itself, since this behavior would be focused on one particular Setting record. We probably want a new class to handle updating the record (which could be called from relevant places in BatchUpdateLogging methods). Then the class could be tested independently of the update process itself.

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Oct 18, 2017

Contributor
  • About the table, yes, it was a misunderstanding, sorry.
  • About the model, should we locate the record in a module in lib, for example? This way could be imported and used e.g. in BatchUpdateLogging.
  • Would you write the info in the settings table, btw?
  • I've seen that all the logs are written to Sentry, right? Is there any way of accessing them?

Maybe I am asking too much but I am trying very hard to understand. So what I understood so far is that the new module would create a new Class that could have different methods, that we could call from BatchUpdateLoggin or ConstantUpdate, for example. We would then calculate the avge time the last 10 updates (Constant Update + Daily Update) took and save this time in a hash, together with the date of the last update (the last one of them two).

Contributor

mauditecandela commented Oct 18, 2017

  • About the table, yes, it was a misunderstanding, sorry.
  • About the model, should we locate the record in a module in lib, for example? This way could be imported and used e.g. in BatchUpdateLogging.
  • Would you write the info in the settings table, btw?
  • I've seen that all the logs are written to Sentry, right? Is there any way of accessing them?

Maybe I am asking too much but I am trying very hard to understand. So what I understood so far is that the new module would create a new Class that could have different methods, that we could call from BatchUpdateLoggin or ConstantUpdate, for example. We would then calculate the avge time the last 10 updates (Constant Update + Daily Update) took and save this time in a hash, together with the date of the last update (the last one of them two).

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Oct 18, 2017

Contributor

Meanwhile I added an UI fix with a general warning, that I think can already help the user :)

Contributor

mauditecandela commented Oct 18, 2017

Meanwhile I added an UI fix with a general warning, that I think can already help the user :)

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Oct 19, 2017

Member

About the model, should we locate the record in a module in lib, for example? This way could be imported and used e.g. in BatchUpdateLogging.

I think SpecialUsers presenter is a good exemplar for how it could be done; it also exists to provide access to data in a particular Setting record. Since this will probably be a class that we will want to use for both writing and reading, though, it probably makes sense to keep in in app/models (as a plain, non-ActiveRecord model).

Would you write the info in the settings table, btw?
Yes. The Settings table is designed to be very flexible about the data it stores; basically, you can any raw data — strings, numbers, arrays of strings and numbers — into a hash and save it. It would probably even be convenient to store the same log we send to Sentry.

I've seen that all the logs are written to Sentry, right? Is there any way of accessing them?

I have access to them, but they are not publicly viewable. Here's what a typical one looks like:

[
 2017-10-19 16:25:42 UTC - Ready to update 340 courses,
 2017-10-19 16:25:42 UTC - Importing revisions and articles for all courses,
 2017-10-19 16:26:35 UTC - Matching assignments to articles and syncing titles,
 2017-10-19 16:26:39 UTC - Importing wp10 scores for all en.wiki revisions,
 2017-10-19 16:26:52 UTC - Checking for plagiarism in recent revisions,
 2017-10-19 16:26:53 UTC - Updating views for newly added articles,
 2017-10-19 16:26:53 UTC - Updating ratings for new articles,
 2017-10-19 16:26:53 UTC - Backfilling Commons uploads for needs_update courses,
 2017-10-19 16:26:53 UTC - Updating ArticlesCourses cache,
 2017-10-19 16:28:53 UTC - Updating CoursesUsers cache,
 2017-10-19 16:31:20 UTC - Updating Course cache,
 2017-10-19 16:35:30 UTC - Finished updating cached values,
 2017-10-19 16:35:30 UTC - Updating greeting status of ungreeted students,
 2017-10-19 16:39:11 UTC - Generating AfD alerts,
 2017-10-19 16:39:19 UTC - Generating discretionary sanctions alerts,
 2017-10-19 16:39:21 UTC - Generating DYK alerts,
 2017-10-19 16:39:21 UTC - Generating course alerts,
 2017-10-19 16:39:34 UTC - Generating survey response alerts,
 2017-10-19 16:39:34 UTC - Update finished
]

Maybe I am asking too much but I am trying very hard to understand. So what I understood so far is that the new module would create a new Class that could have different methods, that we could call from BatchUpdateLoggin or ConstantUpdate, for example. We would then calculate the avge time the last 10 updates (Constant Update + Daily Update) took and save this time in a hash, together with the date of the last update (the last one of them two).

Yes, something like that. I think it would make sense to keep completion times for both the last 10 Constant updates and the last 10 Daily updates, as well as:

  • the logs for the last Constant and last Daily
  • the completion time of the last Daily and last Constant
  • the start time and type of the currently-running update.
Member

ragesoss commented Oct 19, 2017

About the model, should we locate the record in a module in lib, for example? This way could be imported and used e.g. in BatchUpdateLogging.

I think SpecialUsers presenter is a good exemplar for how it could be done; it also exists to provide access to data in a particular Setting record. Since this will probably be a class that we will want to use for both writing and reading, though, it probably makes sense to keep in in app/models (as a plain, non-ActiveRecord model).

Would you write the info in the settings table, btw?
Yes. The Settings table is designed to be very flexible about the data it stores; basically, you can any raw data — strings, numbers, arrays of strings and numbers — into a hash and save it. It would probably even be convenient to store the same log we send to Sentry.

I've seen that all the logs are written to Sentry, right? Is there any way of accessing them?

I have access to them, but they are not publicly viewable. Here's what a typical one looks like:

[
 2017-10-19 16:25:42 UTC - Ready to update 340 courses,
 2017-10-19 16:25:42 UTC - Importing revisions and articles for all courses,
 2017-10-19 16:26:35 UTC - Matching assignments to articles and syncing titles,
 2017-10-19 16:26:39 UTC - Importing wp10 scores for all en.wiki revisions,
 2017-10-19 16:26:52 UTC - Checking for plagiarism in recent revisions,
 2017-10-19 16:26:53 UTC - Updating views for newly added articles,
 2017-10-19 16:26:53 UTC - Updating ratings for new articles,
 2017-10-19 16:26:53 UTC - Backfilling Commons uploads for needs_update courses,
 2017-10-19 16:26:53 UTC - Updating ArticlesCourses cache,
 2017-10-19 16:28:53 UTC - Updating CoursesUsers cache,
 2017-10-19 16:31:20 UTC - Updating Course cache,
 2017-10-19 16:35:30 UTC - Finished updating cached values,
 2017-10-19 16:35:30 UTC - Updating greeting status of ungreeted students,
 2017-10-19 16:39:11 UTC - Generating AfD alerts,
 2017-10-19 16:39:19 UTC - Generating discretionary sanctions alerts,
 2017-10-19 16:39:21 UTC - Generating DYK alerts,
 2017-10-19 16:39:21 UTC - Generating course alerts,
 2017-10-19 16:39:34 UTC - Generating survey response alerts,
 2017-10-19 16:39:34 UTC - Update finished
]

Maybe I am asking too much but I am trying very hard to understand. So what I understood so far is that the new module would create a new Class that could have different methods, that we could call from BatchUpdateLoggin or ConstantUpdate, for example. We would then calculate the avge time the last 10 updates (Constant Update + Daily Update) took and save this time in a hash, together with the date of the last update (the last one of them two).

Yes, something like that. I think it would make sense to keep completion times for both the last 10 Constant updates and the last 10 Daily updates, as well as:

  • the logs for the last Constant and last Daily
  • the completion time of the last Daily and last Constant
  • the start time and type of the currently-running update.

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Oct 25, 2017

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Oct 26, 2017

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Oct 26, 2017

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Oct 26, 2017

Contributor

Sorry for the github Spam. I closed the PRs and will reopen them once I have a more stable solution. Sorry again!

Contributor

mauditecandela commented Oct 26, 2017

Sorry for the github Spam. I closed the PRs and will reopen them once I have a more stable solution. Sorry again!

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Oct 26, 2017

Member

No worries!

Member

ragesoss commented Oct 26, 2017

No worries!

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Oct 31, 2017

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Oct 31, 2017

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Nov 2, 2017

Contributor

Another PR for this issue: #1484

Contributor

mauditecandela commented Nov 2, 2017

Another PR for this issue: #1484

ragesoss added a commit that referenced this issue Nov 8, 2017

New Ux for update log #1005 (#1485)
* adds temporary fix for statistics #1005

* fix indentation

* Adds presenter and method to the batch_update_logging #1005

* fix indentation

* Revert "Adds presenter and method to the batch_update_logging #1005"

This reverts commit 5a40a2c.

* Adds presenter and method to the batch_update_logging #1005

* Revert "Adds presenter and method to the batch_update_logging #1005"

This reverts commit 5a40a2c.

* - Adds MetricsUpdate presenter that adds the last update time
- Adds Rails.cache method to create a temporary record for the last update time

* - Adds specs to test if Settings was written
- Moves MetricsUpdates to Models (as it writes in the db)
- Adds new method only to add a last_update value
- Adds the last_update method to BatchUpdateLogger

* Removes the settings spec from the constant update spec

* adds metrics updates spec

* - adds method to retrieve the last update
- adds specs for that method

* - Adds a last_update method to the course model
- Adds this information to the course json builder
- Includes a new Title with an information bubble to inform about the updates
- Creates different locales for each kind of information

* fixes js small bug

* - Changes wording from MetricsUpdates to UpdateLog
- Adds new getter method to UpdateLog and deletes it from Course Model
- This new getter method gets the time of the last update and formats it
- Adds new tests for the new method at Update Log
- Replaces the old methods with the new ones
- Changes translations to fit the new formatting

* fixes constant update spec

* Fixes update log specs

* fixes spec related to time - failed in travis

* adds small warning for the statistics update

* - Adds new design for the statitics warning message
- Deletes not needed translations

* clean up linting errors

* adds statistics only if the course has not ended

* does not updatelog if its a daily update

* - Cleans up UpdateLog
- Creates setter method to avoid the check up

* fixes typo in the batch update logging

* fixes specs errors

* - Shows statistics only if the course is not ended
- Creates a separate variable outside of the render for the statistics
- Uses moment.js to show how much time is passed from the last update

* show stats only if its not wiki ed dashboard

* replaces OR by AND at courseStatistics

* introduces an if condition based on the class instead of the message
@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Dec 5, 2017

Contributor

@ragesoss I will continue with this issue for my first day at Outreachy if you don't have anything against it. ^^

Contributor

mauditecandela commented Dec 5, 2017

@ragesoss I will continue with this issue for my first day at Outreachy if you don't have anything against it. ^^

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Dec 5, 2017

Member

@mauditecandela sounds good. We should also find some time to meet soon.

Member

ragesoss commented Dec 5, 2017

@mauditecandela sounds good. We should also find some time to meet soon.

@mauditecandela

This comment has been minimized.

Show comment
Hide comment
@mauditecandela

mauditecandela Dec 5, 2017

Contributor

@ragesoss sure. I wrote you on slack :) Let me know about your schedule.

Contributor

mauditecandela commented Dec 5, 2017

@ragesoss sure. I wrote you on slack :) Let me know about your schedule.

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Dec 7, 2017

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Dec 8, 2017

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Dec 8, 2017

mauditecandela added a commit to mauditecandela/WikiEduDashboard that referenced this issue Dec 8, 2017

ragesoss added a commit that referenced this issue Dec 13, 2017

ragesoss added a commit that referenced this issue Dec 13, 2017

@ragesoss

This comment has been minimized.

Show comment
Hide comment
@ragesoss

ragesoss Jan 9, 2018

Member

Done.

Member

ragesoss commented Jan 9, 2018

Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment