this should be a production department decision - its nothing to do with this repo

The mailing lists are all but abandonware these days, and I refuse to engage in these types of discussions in a closed platform like Glip, and few leaders visit the forums unless it involves me trolling the project, so...

They don't look too abandoned.

• Updated 5 days ago
• Updated on 13 Feb
• Updated on 28 Dec 2019

Those dates are unreliable. GitHub shows a repository updated if someone opens or closes a pull request as an example.

Using this repo as an example...

The last update to a branch on this repo was 2 hours ago. GitHub says the repo was last updated 1 hour ago, when the most recent pull request was opened.

So, using those dates alone is not an indicator of life on the repository. More data analysis is required, such as looking at how long it took Weblinks 3.7 to actually be released, or looking at how nobody has addressed any issues with the latest broken version of com_patchtester over the last 5 months, to be able to draw conclusions that the project's resources are spread too thin and that it needs to no longer commit to stretching itself so thin it can't sustain or focus on what's actually important. If the resources in this organization are important to the community, then the community will pick up maintenance on them, but it does not have to be under the Joomla umbrella. Likewise, if these resources are so critical to the project, then the project should allocate appropriate time to them.

I single handedly made changes to improve PHPUnit version coverage on 80+ active development branches in 40+ active repositories in the span of 10 hours. Why is it so hard for the project to allocate 10 hours to one of a number of resources that clearly need attention?

Latest Commit dates on the repos:
Weblinks was updated 5 days ago on the 4.0 branch.
Patchtester was updated 2019-11-09 on the 4.0 branch.
JedChecker was updated 2019-10-13

So the dates by @jeckodevelopment aren't that much off actually.

But I think you raise a valid point. We don't have the ressources to maintain those projects. I'm just not sure if closing the joomla-extensions organisation helps anything.

They would have more visibility on this GitHub account. The reasons for the separate account no longer applies.

Aside from the Framework org when it was originally set up as a monorepo with git subsplit (the same way Laravel and Symfony split their packages to separate repos so you can use them individually and not rely on the full-stack framework), there were never any good reasons to have more than one GitHub organization other than GitHub's pricing model for organizations (since then Joomla now receives a premium account for free) and "but we don't want to put too many projects in one spot, that'll be confusing" (which if I remember right, this is not an exaggeration). Having the joomla-projects, joomla-extensions, and to a lesser degree joomla-framework GitHub organizations just makes it harder to find things (because the projects and extensions orgs aren't in any of the .org nav hierarchy and those are the main workspaces for the "optional" extensions or GSoC projects or other larger "major" feature projects, at least the framework org is linked from that subdomain) and increases management overhead.

So as I said there is no good reason anymore to have multiple github accounts (especially when some of them are only known about through searching github)

given what happened at GitHub level with the changes in the past years, it would be better to consolidate the projects under one organization.
Easier and cleaner. But this should be @HLeithner / @marcodings and Production Dept. call

@jeckodevelopment @Bakual It doesn't help much if e.g. for the patchtester some PRs with corrections have been merged but there hasn't been made any new (beta) release containing these changes.

My point here isn't visibility of different repos. My point is the lack of resources to keep up with everything. The resources just aren't there, as is typical in Joomla. Instead of pretending they are, and people making empty promises to look after something, the project needs to come out and say "we're downsizing, we don't have the resources to keep up with ~120 GitHub repositories" (rough count across the 4 GitHub orgs for anything not marked archived) and find a way to downsize what it's keeping up with. The easy wins right now are search and weblinks, it seems patch tester is in a state of flux, and the 3.x version of the install from web plugin could practically go on auto-pilot at this point short of a major architectural change; and that's just one organization where 4 of 6 "active" repos are in a questionable state.

surely we need to rethink and downsize "projects" based on statistacal data based on actual/current active contributors, and not based on dream

The Repos in extensions are either being maintained or have been archived. I think the concept of keeping them in a separate repo for now is fine until/unless we choose to do a bigger overhall of our github projects and repos

As usual, status quo wins when there is obvious room for improvement. m'eh