canonical.com icon indicating copy to clipboard operation
canonical.com copied to clipboard

Published 20 hours ago • verified publisher icon canonical

out of date projects directory

Open setharnold opened this issue 1 year ago • 6 comments

Hello, the projects directory at https://canonical.com/projects/directory feels fairly out of date:

  • several of the employees are no longer with the company
  • several of the projects are no longer with the company
  • many of the names on the list feel like just a manager from the reporting chain of someone who left and not actually someone who is aware that their name is on the project

I propose deleting this page: it is far enough out of date that trying to repair it doesn't feel like it would repay the effort.

Thanks

setharnold avatar Jul 19 '23 17:07 setharnold

It's certainly nice to have a complete listing; but, I agree that it would be tough to manage a list of every project, the involved teams and individuals, and their contact information.

Perhaps we could programmatically pull from public information and APIs, e.g. the Canonical GitHub and the derivative teams on LaunchPad. This would lower the maintenance overhead while moving the source of truth to places where these kinds of changes are already evident.

johnlettman avatar Jul 19 '23 20:07 johnlettman

Having a real list of our projects and who owns them would be fantastic. We've got two spreadsheets and a wiki https://wiki.canonical.com/UbuntuEngineering/Security/InternalAlerts to try to keep track and they're basically always out of date. Tracking down who to contact for a project is a chore half the time.

setharnold avatar Jul 21 '23 00:07 setharnold

@setharnold Here's an example of the concept mentioned above. https://gist.github.com/johnlettman/611d20639ef6e722dacddcf7b7a4f7f2

The server-side implementation should likely cache the data for a lengthy bit of time for processing and API etiquette's sake. I played around with identifying the "repository owner," e.g., scanning the most significant contributors or issue assignees, but there are no good ways.

An equivalent is undoubtedly possible for Launchpad using group traversal.

Looking at the available documentation, it seems we have a pretty good breakdown of overarching project domain ownership; however, the "open source projects directory" page seems to imply a detailed listing, requiring a commensurate source of truth.

I'm not sure my API scraping approach is 100% the right way to do it, given the sheer mass of repositories across all business units. It may be too much for that page. On the other hand, I'm certain it's a monotonous task for a human. :man_shrugging:

johnlettman avatar Jul 21 '23 04:07 johnlettman

@juanruitina may know who owns this section of the site? we usually have product owners managing the content and this can be a copy update maybe @egezeytun

carkod avatar Jul 25 '23 12:07 carkod

@Sophie-32 can you add this to our meeting agenda for tomorrow? We will need to determine (or decide on) the copy owner for this one as well.

egezeytun avatar Jul 25 '23 13:07 egezeytun

I discussed this with the engineering leadership two weeks ago and I tasked them with refreshing the copy doc for this page. I will follow up with them individually with any outdated content.

anthonydillon avatar Jul 26 '23 03:07 anthonydillon

The issue was closed in this PR: https://github.com/canonical/canonical.com/pull/1146

lizzochek avatar Sep 10 '24 13:09 lizzochek