Maintaining this project and Admin rights

[Potherca]

At the moment of this writing, this project is activelu maintained by @jrfnl, @mjrider and myself.

However, only @mjrider has admin access. In order to make sure we have a smaller bus factor we need a higher admin redundancy.

From what I can see, to keep things running smoothly, admin acces is needed to:

• [x] Github
• [x] Packagist
• [x] Travis

There has also been (offline) talk about moving this package away to another, separate Github Organisation, as development is currently not actively supported/endorsed by Dealerdirect.

That would presumably also make it easier to manage admin rights, etc.

This would not need to happen ASAP, but definitely needs to be resolved before we "go stable".

Can I get some feedback regarding this topic? What do you feel is a good course of action? Did I miss anything?

[jrfnl]

Can I get some feedback regarding this topic? What do you feel is a good course of action?

I concur that two admins are better than one. Issues #110 and #112 both have been opened because committers are running into this.

In my experience, once someone has admin rights on GH for a project, this trickles through automatically to Travis and I think, even to Packagist, though I'm not 100% sure about that one.

There has also been (offline) talk about moving this package away to another, separate Github Organisation

If it would help, the OS organisation PHPCSStandards could be considered a candidate for moving the project to. In that case, no new organisation would be needed and I'd be happy to grant the relevant people the necessary rights.

[mjrider]

i forgot to comment it here, but i made @Potherca admin also when this ticket was opened. if he can verify that it also works for travis.

For moving the project, with keeping backwards compatibility and all that i think that would be a good thing to do

[Potherca]

I've have access to all three linked resources. I've added @jrfnl to Packagist and also made them admin in GitHub.

@jrfnl can you verify you can access Travis at https://travis-ci.com/github/Dealerdirect/phpcodesniffer-composer-installer/settings?

If so, we can close this ticket, I'll make a new/separate one for discussion if/when/where to move the repo before we go stable. (As I get the feeling that moment is creeping closer...)

[jrfnl]

@Potherca Looks like I'm all set. I can confirm I can now access GH admin, Packagist admin, Travis settings.

I'll make a new/separate one for discussion if/when/where to move the repo before we go stable. (As I get the feeling that moment is creeping closer...)

Before going stable, more than anything, I'd like to see a (minimal) test setup in place with a relatively easy way to add more tests. Other than that, I agree that seeing fewer support requests and bug reports coming in over the last six months is a good indication that we're nearing "stable".

For moving the project, with keeping backwards compatibility and all that i think that would be a good thing to do

Re: moving and BC:

• As it would essentially still be the same project, just moved, the package name for Packagist would not need to change.
• If the GH tooling is used to move (tranfer) the project, GH will automatically redirect the old repo URL to the new one.

If the choice would be made to change the Package name for Packagist, I'd need to check if there is a good way to do that without breaking things. Can't remember precisely at this moment, though we did go through something like this with PHPCompatibility.

[GaryJones]

https://github.com/composer/packagist/issues/47 has the current process.

[jrfnl]

@GaryJones Just looked through it and that feels like exactly what we did for PHPCompatibility.