Choose some precise (or rough) way to "adopt" modules in the Raku Module Adoption center

[JJ]

As you probably know, many (if not the majority) of modules in the Raku module adoption center (a.k.a. community modules) are abandoned, with years-old issues, and mostly left to bitrot for good.
Even in some cases where they are (roughly) taken care of, people step onto each other's work, or simply ignore each other, working on main and simply changing.
This might lead to confusion, sometimes frustration, but mostly abandonment of modules that are already abandoned.
What I would want is some rough policy for these modules that would cover stuff such as

• General policy for changes in them
• Release policies
• Real adoption policies, that is, how they should be moved to someone's repo.

[2colours]

I very much welcome bringing this up.

Lately, I've been trying to touch everything that seemed remotely interesting, clearing up issues and PR's. I still have a pending PR for App::Mi6, mostly unwelcome - I wanted to revive Ddt but it mostly deteriorated.

I got access granted to named group, and I felt this was actually a step forward. I finally knew my modifications won't be dangling forever. At the same time, I wouldn't want to claim exclusive ownership of all these modules that I might touch because not sure if I can maintain them on my own in the long run.

To me, the following things seem to be the biggest problems:

• release policies. I'm done with my modification and want to publish it. How can I do that? Is there a mechanism hooked to git, based on labels for example; or do we just downright rely on who has access to the one single fez account?
• workflow processes. As you pointed out, it can happen that multiple people "claim" the same shared module simultaneously. There is no formal process of collaboration in this case.

Regarding "real adoption", as I implied, I have mixed feelings. I think adoption can solve the "workflow process" problem (and in some sense the "release" problem as well; although it introduces further fragmentation in the ecosystem), however I believe adopted modules are at least as much prone to abandonment, and then they are really lost for good. Ddt isn't even the worst case that can happen. Talking for myself, I may want to adopt some modules I touch; most of them I'd only like to polish, directly accessing the rot feeling you mentioned.

[JJ]

I very much welcome bringing this up.

Lately, I've been trying to touch everything that seemed remotely interesting, clearing up issues and PR's. I still have a pending PR for App::Mi6, mostly unwelcome - I wanted to revive Ddt but it mostly deteriorated.

Sorry to have caused confusion here. I'm specifically talking about modules we, as a community, are responsible for, hosted by the Raku community modules org.

Whatever is done to "private" modules is under the responsibility of their owners. It might or might have some merit to create some ecosystem-wide policy, but that's not what I was talking about here.

I got access granted to named group, and I felt this was actually a step forward. I finally knew my modifications won't be dangling forever. At the same time, I wouldn't want to claim exclusive ownership of all these modules that I might touch because not sure if I can maintain them on my own in the long run.

This is not about forcing. It's more about acknowledging who are stakeholders in a specific, community-adopted module.

To me, the following things seem to be the biggest problems:

* release policies. I'm done with my modification and want to publish it. How can I do that? Is there a mechanism hooked to git, based on labels for example; or do we just downright rely on who has access to the one single fez account?

There's a fez account for the organization.

Regarding "real adoption", as I implied, I have mixed feelings. I think adoption can solve the "workflow process" problem (and in some sense the "release" problem as well; although it introduces further fragmentation in the ecosystem), however I believe adopted modules are at least as much prone to abandonment, and then they are really lost for good. Ddt isn't even the worst case that can happen. Talking for myself, I may want to adopt some modules I touch; most of them I'd only like to polish, directly accessing the rot feeling you mentioned.

Again, I'm not talking about Ddt, who's got its properly qualified owner. That's a different topic.

[2colours]

Sorry to have caused confusion here. I'm specifically talking about modules we, as a community, are responsible for, hosted by the Raku community modules org.

There is no confusion on my side. I just brought up a few examples why "Raku community modules" is an important concept - it's really hard to contribute to random "private owned" Raku modules, even though some of them are admittedly abandoned, like Ddt. I wish that was also "donated" to the community domain.

This is not about forcing. It's more about acknowledging who are stakeholders in a specific, community-adopted module.

So, if I understand you right, the idea is to clarify maintainers within the organization?

There's a fez account for the organization.

I know that but someone who has just joined the contributors, like myself, probably wouldn't have access to it; and honestly, if it's really just one shared account, I'm not sure if it's a good idea in the first place to grant people login access to it.
However, if this is something a few trusted individuals can manage, then we have a bottleneck for releases so I wouldn't overlook this problem.
Once upon, it was mentioned that maybe fez could handle associations in some shape or form; not sure how feasible that is right now but it would be a much more comforting and sustainable position to be in.

Again, I'm not talking about Ddt, who's got its properly qualified owner. That's a different topic.

I don't think so, for multiple reasons:

1. Ddt's properly qualified owner doesn't use Raku anymore. I've tried to adopt it, the rest I have already said.
2. considering the license note, it seems that Ddt itself is adopted software some way.

Considering these factors, I think it's a perfect illustration for modules that would have a happier place in the "adoption center", and what could possibly happen to some prematurely adopted modules.

[JJ]

Sorry to have caused confusion here. I'm specifically talking about modules we, as a community, are responsible for, hosted by the Raku community modules org.

There is no confusion on my side. I just brought up a few examples why "Raku community modules" is an important concept - it's really hard to contribute to random "private owned" Raku modules, even though some of them are admittedly abandoned, like Ddt. I wish that was also "donated" to the community domain.

Be that as it may, the title of this problem explicitly mentions the Raku Module Adoption Center. I would really prefer we stick to that issue, and I will most definitely not discuss anything that's not related to that.

This is not about forcing. It's more about acknowledging who are stakeholders in a specific, community-adopted module.

So, if I understand you right, the idea is to clarify maintainers within the organization?

Correct. Including someone else that, for whatever reason, have access to that repository.

There's a fez account for the organization.

I know that but someone who has just joined the contributors, like myself, probably wouldn't have access to it; and honestly, if it's really just one shared account, I'm not sure if it's a good idea in the first place to grant people login access to it. However, if this is something a few trusted individuals can manage, then we have a bottleneck for releases so I wouldn't overlook this problem. Once upon, it was mentioned that maybe fez could handle associations in some shape or form; not sure how feasible that is right now but it would be a much more comforting and sustainable position to be in.

Please read above. Fez is perfectly able to handle "associations" (organizations, that is), which is what I'm saying above.

[2colours]

Be that as it may, the title of this problem explicitly mentions the Raku Module Adoption Center. I would really prefer we stick to that issue, and I will most definitely not discuss anything that's not related to that.

My comment implicitly mentioned the Raku Module Adoption Center, and I think I've spent enough time to clarify that. Also, both of us are mentioning the abandonment of modules which can happen inside the Raku Module Adoption Center and outside of it, there are precedents for both. I'd say this is strongly related to the issue and frankly, even if you disagree with that for whatever reason I cannot see, it's frustrating that I welcome an issue that bears huge significance for whatever I've been doing in the last 3 months and someone superficially dismisses it out loud.

Please read above. Fez is perfectly able to handle "associations" (organizations, that is), which is what I'm saying above.

Well then, could you please elaborate on that, or at least link where I could find more about this "organization" feature? How do you, for example, make a community module release using fez? Just saying that there is a fez account does not help, I already knew that. I also have a fez account and I kinda hope you cannot make releases to my modules with it...