The Infrastructure Working Group (IWG) is a committee chartered by the Perl Foundation to manage technical infrastructure, both that used by TPF directly and that which benefits the Perl and Raku communities.
You might want to read our charter or, less likely, our rules of operation.
Here, more or less, is the pitch that was used to create this group:
Sometimes, individuals or small teams produce work that comes to have value to Perl or Raku programmers. With that work effectively delivered, spending time on it is no longer interesting. The original authors stop paying attention to the project, which is now running on a cloud instance somewhere, probably requiring no maintenance. Occasionally, it may need to be rebooted, but mostly it chugs along. While this is happening, it remains useful, and so its audience can grow, and now more people rely on this tool, even as its authors become less interested. Eventually, the tool falls over and the authors, who hold the only access to the system, are basically unavailable.
Sometimes, this even leads to some other interested party spinning up a new install of the original site's software (because it may be open source), but this can lead to a second collapse, when that second party is no longer interested.
This means the goals of the IWG include:
- creating a team who will maintain these systems, keeping them up and running as long as they have value, possibly long after the original authors have lost interest
- ensuring that the team itself can have, and does have, rotating membership so that we don't realize after four years that everyone on the team designed to create continuity has, in fact, vanished into the mist
- creating an incentive for authors of these tools to hand engage with this team so that the project has a chance for continuity from the start; in other words, avoid the TPF-maintained instance from being the second install of the tool
- producing standards of operation for infrastructure so that any new project brought under the fold of this team causes as little increase as possible to the overall cognitive load of working on this team; chief among these standards must be "sufficient documentation" and "an escrow of privileged access to managed systems"
- establishing the nature of ownership of the project; for example, can the original owner reject changes to the software that the infrastructure team judges necessary for ongoing operation?