Subject: BUG #15706: Support Services page out of date

From: PG Bug reporting form <[email-masked]>
Date: Tue, 19 Mar 2019 19:18:00 +0000

The following bug has been logged on the website:

Bug reference:      15706
Logged by:          Jon Tara
Email address:      [email-masked]
PostgreSQL version: 10.5
Operating system:   Linux
Description:        

This page:

https://www.postgresql.org/support/professional_support/northamerica/

Has a LARGE number of out-of-date and incorrect listings.

A few of them that I noticed:

Data Egret - phone number out of service
Consistent State - Website does not work
Datakings - website 404
EDB - Answering machine, with no identification, there is a different number
on website
OmniTI - "Sorry, we're closed" message on website, employees joined or
formed Credativ
OpenSGC - Acquired by Amazon
Stormatics - no response from website

This makes it a frustrating experience trying to use the page for it's
intended purpose. Google search is more useful.

---

From: Euler Taveira <[email-masked]>
Date: Wed, 20 Mar 2019 14:55:25 -0300

> Has a LARGE number of out-of-date and incorrect listings.
[redirecting to www...] Should we ask for confirmation every x months?

--
   Euler Taveira                                   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 20 Mar 2019 16:12:10 -0400

> [redirecting to www...] Should we ask for confirmation every x months?

I did an audit of it a few years back, we are due for another one (and
something on my TODO for this year). When I did the audit, it took
several weeks to review all of the listings, so without additional help,
"every x months" is not reasonable.

Additionally, it also depends what is "out of date" -- if they are
companies that no longer exist, yes, the listing should be removed. If a
company does not keep up to date the # of employees, or its offerings,
etc., that's not something we can really control.

Jonathan

---

From: Euler Taveira <[email-masked]>
Date: Wed, 20 Mar 2019 20:11:25 -0300

> "every x months" is not reasonable.
Jonathan, I appreciate your effort. I'm suggesting an automated way to
check the list (send an URL by email for confirmation). If there is no
response, stop to show that company. Company can always enable it
again. Periodic notification can encourage companies to keep their
info up to date. I'm not volunteering to do the work.

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 20 Mar 2019 20:20:17 -0400

> info up to date. I'm not volunteering to do the work.

Some of the pgweb folks have discussed doing that before; it's not a bad
idea, and perhaps would cut down on some of the headaches.

If we went down that route, I think we would want to borrow from some of
the pgeu codebase, which I believe has reminder infrastructure set up,
and then apply it to this. If we went down this path, it'd be good to
apply it to products in the software catalog as well.

Jonathan

---

From: Magnus Hagander <[email-masked]>
Date: Sun, 24 Mar 2019 18:50:37 +0100

> idea, and perhaps would cut down on some of the headaches.

That was in fact the original plan, nobody just got around to building it.
There was even a db field for it in the early dev snapshots, but it was
removed since it was never quite done.

The general idea was to just have a "last confirmed" timestamp field on
each entry, and just stop showing any entries that have not been confirmed
in <n> days/weeks/months/whatever. We can keep them around some extra time
beyond that in case people come back to update them later of course.

> apply it to products in the software catalog as well.

I think we pretty much have all the needed parts already. All that's needed
is a "last reminded" field along with the "last onfirmed" one above, and
decide on a schedule between those two for sending reminders.

Oh, and +1 for doing the same for products.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

---

From: Daniel Gustafsson <[email-masked]>
Date: Mon, 25 Mar 2019 09:33:07 +0000

On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <[email-masked]> wrote:

> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <[email-masked]> wrote:
>
> That was in fact the original plan, nobody just got around to building it. There was even a db field for it in the early dev snapshots, but it was removed since it was never quite done.
>
> The general idea was to just have a "last confirmed" timestamp field on each entry, and just stop showing any entries that have not been confirmed in <n> days/weeks/months/whatever. We can keep them around some extra time beyond that in case people come back to update them later of course.

I think it makes sense to remove after a set timeout, if the user hasn't verified in 3 months (or some
other sufficiently long period) then the odds that the entry is out of date seems quite high.

> Oh, and +1 for doing the same for products.

+1

cheers ./daniel

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Fri, 26 Apr 2019 23:48:01 -0400

On 3/25/19 5:33 AM, Daniel Gustafsson wrote:
>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> That was in fact the original plan, nobody just got around to building
>> it. There was even a db field for it in the early dev snapshots, but
>> it was removed since it was never quite done.
>>
>> The general idea was to just have a "last confirmed" timestamp field
>> on each entry, and just stop showing any entries that have not been
>> confirmed in <n> days/weeks/months/whatever. We can keep them around
>> some extra time beyond that in case people come back to update them
>> later of course.
> 

So I had (made?) a chunk of uninterrupted time and went ahead and did a
manual scrub of the professional services page with a test for the
proposed above algorithm. Summary and details to follow:

Looking at the timestamp on some of the old moderation comments, it
turned out the last scrub was almost 5 years to the day. Oops, time flies :(

When looking at the listed services, the main thing I checked was did
the website that was linked to from the service indicate the
organization supported PostgreSQL or PostgreSQL-related product in some
way -- this made it a fairly low bar to clear. I bucked each service
into one of 3 categories:

1. OK: I was able to find their PostgreSQL offering

2. Send a Follow-up: Website was still active & looked like a technology
provider, but no clear indication of PostgreSQL offering. This I think
is the simulation of how the "please perform this update" automation
would work

3. Remove: website was dead / company did something completely different
/ site redirected me to things I would like to unsee. All the more
reason to scrub the data.

The scrub took me about 2 hours and change.

- 167 of the listings fell into category 1
- 28 required follow-ups (category 2) and I sent as such providing a
reasonable timeline to provide at least some update (one week)
- 39 fell into category 3 and were remove.

Based on the last time I did this, I think ~25% of the category 2
organizations will get back and make the necessary updates, so assume we
remove that much  more.

Anyway, the data was much more stale than I thought it would be :( But
I'm not surprised, either.

This is also a long way of saying that I think we should proceed with
the solution to help automate this. After going through the painstaking
process again, I'd recommend it works kind of like this:

- An email goes out once every {6 months, 1 year} to the organizational
contact that says something like: "Hi, This is an automated check to
ensure your company is still an active PostgreSQL service provider.
Please click the URL provided to confirm. <UniqueURL> If you do not
confirm within 7 days, your listing will be unpublished"

- If user clicks URL, it is confirmed and the last_confirmed_date is set
to CURRENT_DATE

- If user does not click URL, we set the entry to unpublished. This
would put it into the moderator feed, and one of the pgweb moderators
can then take further action if need be.

Anyway, products needs a scrub as well, which I will try to block out
some time for in the coming days to handle those as well. Those should
hopefully not take as much time as they are a bit easier to verify.

Thanks,

Jonathan

---

From: Magnus Hagander <[email-masked]>
Date: Sat, 27 Apr 2019 12:41:09 +0200

> proposed above algorithm. Summary and details to follow:

Thanks! That must've been a painful couple of hours :)

<snip>

> confirm within 7 days, your listing will be unpublished"

7 days might be a bit on the short side. If someone is unlucky they get the
notification while on vacation for example, and then they're delisted
before they can even see it.

> can then take further action if need be.

That's pretty close to my original thoughts around that, except I'd just
delete them as step 3 and not bother the queue.  I'm fine with de-listing
it as well, as long as pgweb moderators are happy to handle that :) That
would also take care of the scenario where the email bounces, by simply
being able to ignore that fact and leave it up to the individual moderator
to handle manually.

> Cool. Thanks!

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Sat, 27 Apr 2019 09:31:50 -0400

On 4/27/19 6:41 AM, Magnus Hagander wrote:
> 
> 
> On Sat, Apr 27, 2019 at 5:48 AM Jonathan S. Katz <[email-masked]

> 7 days might be a bit on the short side. If someone is unlucky they get
> the notification while on vacation for example, and then they're
> delisted before they can even see it.

Well, that's why I suggested it gets de-listed, so one of us can
manually check and determine if indeed it should be delisted, or it's
the case of out-of-office, or a bad email address, etc.

> delete them as step 3 and not bother the queue.  I'm fine with
> de-listing it as well, as long as pgweb moderators are happy to handle
> that :) That would also take care of the scenario where the email
> bounces, by simply being able to ignore that fact and leave it up to the
> individual moderator to handle manually.

I would de-list it. It's certainly easier for a moderator to check a few
of said entries vs. the whole slew.

>     hopefully not take as much time as they are a bit easier to verify.

NP, feels good to do some spring/fall cleaning :)

Jonathan

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Sat, 27 Apr 2019 21:37:53 -0400

>>> Oh, and +1 for doing the same for products. 

OK, so I did the scrub for products.

> The scrub took me about 2 hours and change.

Fortunately, products are a bit more straightforward and did not take as
long as services, though it was still at least an hour. So whatever
system we put in place for services, I suggest the same for products

There were 210 products listed at the beginning of the scrub.

- 170 remain
- 40 were removed as they did not exist + no obvious replacement / went
to things I wish I could unsee.

I would say this was more stale than I thought too, but given that there
has not been a product scrub as long as I can remember, it's not as bad
as the staleness of the services.

Regardless, let's work on getting that system into place to help manage
it so scrubs are less gargantuan tasks.

Thanks,

Jonathan

---

From: Tatsuo Ishii <[email-masked]>
Date: Mon, 29 Apr 2019 06:38:30 +0900 (JST)

> it so scrubs are less gargantuan tasks.

Are we working on this region only?
https://www.postgresql.org/support/professional_support/northamerica/

Some of the companies listed in the northamerica page also appear in
other regions (I only checked aisa though). I think companies removed
from the northamerica region should also be removed from other regions
as well unless they explicitly stat that they have different entities
in the other regions.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Sun, 28 Apr 2019 17:41:30 -0400

Hi Tatsuo,

> https://www.postgresql.org/support/professional_support/northamerica/

I went through every organization that was listed, regardless of region.

> as well unless they explicitly stat that they have different entities

The pgweb schema allows for a professional service to be listed in all
the regions it operates. I did not adjust that; I only removed
organizations that were clearly no longer operating (based on above
definition), and reached out to other orgs for clarifying questions. In
the case of removal, the org was removed from _all_ regions.

Thanks,

Jonathan

---

From: Tatsuo Ishii <[email-masked]>
Date: Mon, 29 Apr 2019 06:49:04 +0900 (JST)

From: "Jonathan S. Katz" <[email-masked]>
Subject: Re: BUG #15706: Support Services page out of date,Re: BUG #15706:
 Support Services page out of date,Re: BUG #15706: Support Services page out of date,Re: BUG #15706: Support Services page out of date
Date: Sun, 28 Apr 2019 17:41:30 -0400
Message-ID: <[email-masked]>,<[email-masked]>

> the case of removal, the org was removed from _all_ regions.

Great! That perfectly makes sense.

BTW, how can companies listed on those pages update the descriptions?
I see new registeration form:
https://www.postgresql.org/account/services/new/

but fails to find update or removal form.

Best regards,

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Sun, 28 Apr 2019 17:51:49 -0400

> but fails to find update or removal form.

They should be listed here:

https://www.postgresql.org/account/edit/services/

I did a quick check and it looks like the SRA OSS Inc. org is associated
with the profile, so you should be able to click on the URL there and
perform any updates.

Thanks!

Jonathan

---

From: Tatsuo Ishii <[email-masked]>
Date: Mon, 29 Apr 2019 07:01:34 +0900 (JST)

> with the profile, so you should be able to click on the URL there and

Thank you for letting know me. It would be nice if the link above is on:
https://www.postgresql.org/support/professional_support/
with a comment something like:
"If your company is already listed here and you want to update the descriptions, please click here."

Best regards,