Subscribe users to their old changesets discussions

[Zverik]

Was: Users are not subscribed to their changeset discussions by default

So when somebody comments a changeset, the user who made that change isn't notified. And the discussion ends there.

Run a script that subscribes users to all discussions for their old changesets (prior to November 2014).

[tomhughes]

They certainly should be, though only for changesets created since the comment feature was added - changesets from before that date will not have the creator subscribed.

[tomhughes]

https://github.com/openstreetmap/openstreetmap-website/blob/master/app/controllers/changeset_controller.rb#L35 is the line of code which takes care of it.

[HolgerJeromin]

IMO i want to get notified if someone has a comment at a 3 years old changeset.

[Zverik]

I also think so. There is nothing different between old and new changesets, and UI doesn't distinguish these. I have changed the issue towards subscribing users to their old changeset comments.

Tom, thanks for pointing out I was partially wrong.

[tomhughes]

I'm not saying it's a bad idea, just that it will mean running a big update on the database.

[Zverik]

Do you have access statistics? Are there periods of low usage? Do we have temporary outages planned for coming months? Maybe run it in small chunks over a week or two?

[ukasiu]

Maybe we could just inverse the effect of entry in the join table for changeset author. What do you think?

[tomhughes]

I have no idea what you're suggesting...

I'm quite happy to add the necessary records, but I'd rather wait until we've expanded the RAID array on the slave server as space is a bit tight at the moment.

[HolgerJeromin]

I think @ukasiu wants to change the own subscription to an blacklist and not a white list. So you are subscribed with no action needed in the DB. But this is probably too late to change.

[Skippern]

I think this could be done in a "slow working script", that way the backward subscription will increase a little over time. There are so many changesets that if we where to subscribe them all in one go than that might mean "freezing" up the API for some hours. Changesets prior to this feature is now more than a month old, so adding changesets to subscription would not be critical, but nice to have. If we add lets say 10.000 changesets an hour, I don't think the load on the server will be too big, and in a couple of weeks most changesets would be added to subscription

[tomhughes]

It won't be done through the API, it will be done with a migration directly on the database. I just need to remember to write it now that the disk space issues are fixed.

[Skippern]

@tomhughes I meant that the load might be so high that it could affect db access, not actually taking the API off, but you probably have better knowledge to the bells and whistles behind there than I have.

[polarbearing]

How is notification of the changeset author working now?

I commented some recent changesets and got not response, which I assumed was due to the nature of these changesets. I commented on a constructive changeset dated 27 Nov 2014 on 3 Dec and learned from the user via classical messages that he did not get notified. I commented one of my own changeset from yesterday, and did not get notified.

[tomhughes]

Fixed in 821a22c which has been (in slightly modified form to avoid lock contention) run on the live database over the last 36 hours.

[Zverik]

Thanks!