The raku-community-modules organization and its problems.

[JJ]

After adoption of the latest dozens of supernovus modules, there are now 101 repositories in the organization. Of these 101 repositories, only 68 are actually released into the ecosystem (this does not include supernovus' modules, which haven't changed to the new URL yet)

I just changed the URLs in META.list to the new one massively, although I should probably have released them one by one to check if they work or not...

I think the original intention of this is to be a "module adoption center", but I think we need to design an endgame for every repo there so that it does not become a "module neglecting center". And there are signs of neglect everywhere, and there will be more if we don't really take charge of this.

• First, about adoption. I am not really for massive adoption of this scale, and even more so when it's simply because the person in charge doesn't want to take care of them. It would have been much more reasonable to help supernovus find people with some specific interests in specific modules to co-manage them. We simply don't have enough resources to perform the simple task of renaming and re-releasing these 30? modules, let alone manage them going forward. I understand that this massive adoption is mostly my fault, because I added supernovus to the team. I didn't know, however, it was for this reason, being able to transfer all these modules easily.
• Second, about neglect. There are all kind of modules here. Some of them are forks, some of them have been transferred, some of them have been released (I guess most), some of them not; some of them have been re-released ("under new management"), some of them rely on GitHub redirect working into the foreseeable future. There's simply no way to know other than going through them, one by one.
• Third, about endgame. Again, I don't see this as a dumping place, same as adoption centers are not a dumping place. Eventually, getting them back to a loving host should be the endgame. I don't see this happening, and also I don't see an easy way of managing the process. But I see many cases where this makes all the sense in the world: DBIish, for instance, is very well managed by a group of persons, and it would probably be a good idea to ask them to own . There's another module, WebService-ICanHazIP that is simply behind the module it was forked from. So I don't see any reason for it to stay here.
• Maybe fourth, there are also some modules in the Raku/ organization. I guess the origin of these is different, but in some cases they've stopped being critical or are also abandoned. Some of them are even in the old Perl6 organization. Maybe we should group all of these together.

There are many things that we could do about this, but the most immediate one, I guess, is simply to get many more people into this organization so that they can help. Eventually, more technical means, policy rules and management procedures should take place, but for the time being simply a bit of more attention is very necessary.

[patrickbkr]

Actually I was the one that initiated and proposed the move of supernovus' modules to community-modules.

The way I understand the community-modules organization is that our community was/is small enough that it's feasable to sometimes have modules maintained by the community in general. This especially makes sense for modules that don't change much. Having such projects in a repository to which many people have access makes it easy to fix stuff as one does not depend on some maintainer to be available. In that sense I never percieved community-modules as a module adoption center.

I think projects that have some direct relation to Raku itself make sense to have in the Raku organization. Modules that have no direct relation to Raku (other than being written in Raku) should not be in the Raku org. Those find a place in community-modules.

The incident that started my conversation with supernovus (which lead to this move) was a set of PRs to one of his modules (TimeZone::DateTime) which he didn't notice. It turned out he is still interested in his modules but doesn't have the time to do much (like merging PRs). Community-modules seemed like a natural fit because then people using the modules, finding and fixing a bug can do so directly without him having to worry about it. He then went through all of his modules and filtered out unused and superseded modules. Only the remaining ones were then moved to community-modules.

[JJ]

@patrickbkr although I refer to that move in the post, it's not really the main problem, it's only brought it to the surface, since it made the organization go over 100 modules to maintain. Already 70 modules were a bit too much, but 100 is really out there. Anyway what's done is done, and we need to move forward now. Even if this issue is only good to attract some attention to those modules, I'd be happy.

[coke]

Recent discussion on IRC has brought this to the fore again. Need to have:

• Documentation on the expected process - how do we decide to adopt modules? How do we rehome them? Do we abandon them?
• How do we handle volunteers, whether with direct commit access or PRs. Do we have certain users in RCM that are "assigned" to certain modules, owners, etc. If we have that, should we try to rehome?
• Manage the github repositories - consistent labels
• Manage releases (e.g. everything should use mi6, versions should be semver, etc.)
• How do we manage issues (starting with https://github.com/issues?q=is%3Aopen+is%3Aissue+org%3Araku-community-modules) We should have a standard set of tags so we can easily find issues for critical issues - and someone needs to manage the tickets across all the repos (everything should have a tag; things without tag haven't been triaged yet...)