For any problems that are not specific to the business, we should look to use publicly available modules and release our own when no suitable existing options are available. Many of our projects are JavaScript, so these modules will probably live on npm.
The guidance below covers the absolute basics, some modules may automate this process and if they do should provide details of how to release them in their own README/documentation.
It's much easier to manage access through adding and removing owners than through resetting the password on an account shared by many people, so you should publish as yourself. Create an account with the npm website and npm login as that account via the CLI.
npm's docs cover the basics of creating and publishing modules. Once your module is in a usable state, you should npm publish, then add the @holidayextras user as an owner (npm owner add holidayextras module-name) - we recommend this to ensure every module we release is under the ownership of at least two people in the organisation.
Release new versions as other projects require changes made to the module; you don't have to release a new version after every pull request is merged.
Speak to someone who previously published the module, or someone with access to the @holidayextras user to get yourself added as a collaborator. Follow semver principles when deciding the new version number to avoid surprising any consumers of the module, and npm publish.
If a public module was released in the past but for whatever reason we no longer have a use for it, passing it on to a new maintainer outside the organisation is an option. If there are no obvious candidates (think people who have submitted pull requests or issues and may still need the module themselves), make it clear in the module's README that it's looking for a new owner to manage the expectations of prospective users.