Add new maintainers

[BenjaminPaap]

@ianare: I noticed you are not maintaining this package anymore. If you are not interested in maintaining this could you please add some new maintainers that some of the pull requests get merged? We're using this in production and need some slightly changes which were proposed as pull requests already (Pull Request #40). Using my own fork and not letting others benefit from my changes feels wrong.

I know that time is something that everyone of us might need more of so let's share maintenance work. I personally would suggest adding the top 2 committers beneath yourself to the project if they also like this idea or someone who is fine with proposing himself to maintain this.

Thanks for your time and effort in coding this.

/cc @monofone, @ch3ric

[ianare]

@BenjaminPaap I developed this lib as part of paid duties. As I am no longer employed by Digitick I don't have admin permissions on their repos. I am also no longer doing any PHP programming...

This should really be handled by @aubryfr and @jdonnat

If they don't answer maybe you can simply set up your fork to be the official repo.

Sorry but that's the best I can do :-(

Cheers,

[BenjaminPaap]

Thanks @ianare for that answer.

So @aubryfr and @jdonnat. Can we do anything to develop this one any further? Should be in your interest too, shouldn't it?

[BorislavSabev]

@BenjaminPaap it will for sure benefit them all. I will also be happy to contribute my own changes that are now only forked locally.

I also have a PHP52 (yes, tragic...) version of this lib if anyone is interested. It uses the Zend1 style namespaces.

If digitick doesn't want to add you in as maintainers (as the case will most probably be) they should at least point to your repo as an up to date source.

Anyway, @BenjaminPaap message me when you figure it out and set up the new repo so that I can lend a hand with some stuff. I broke my head quite a number of times with this already. ;)

[monofone]

@BenjaminPaap thank you for bringing this up. I am not sure about what to do when none of @aubryfr and @jdonnat will reply. But there is a possibility to name a package in composer which should replace another package (https://getcomposer.org/doc/04-schema.md#replace). By this, it is possible to create a fork of the original one and going on to maintain it by another name on packagist.

@ianare you are the responsible of the package at packagist at the moment. Do you still have access to the packagist account and would you like to add additional maintainers to the package ? Then it is possible to go on without a new name and a fork.

For my person I can support in review, maintenance and the discussion if the lib should do math :-)

[BenjaminPaap]

Since now no one from @Digitick got in touch with me. I would prefer using another repository as the official one. I came up with those three suggestions how we could handle the future of this package:

1. I can create a new organization managed by the company I'm employed at (we're some developers loving open source) and fork it to the newly created organization. In the future we would put our open source projects there and create a new team for every project.
2. We vote on some of the many forks to become the new maintained repository.
3. We create a new organization just for this repository

I would vote for 1 or 2. Nr. 3 is just an idea.

[ianare]

@monofone Yes I still have access to the packagist account, let me know which maintainers to add.

[monofone]

@BenjaminPaap I would prefer a combination from 2 and 3 as the problem with 1 we just had. An employee that leaves a company and the repository is no longer maintained.

I´d like to vote for a repository and then create a new organisation from within this repository.

At a first glance @shad0w-rep and @elrico77 looks good, but both last changes are not in a single repository so the first step should be to checkout the changes done in all the other repositories and bring them together to get the whole knowledge collected over the past months.

[BorislavSabev]

Guys I'd be heppy to participate.

[monofone]

I tried to merge different fixes and improvements together to get the most out of the community efforts. I hope the changes are all merged correctly and asking the named committers to check if the changes merged are working as expected. I`m happy about the up counting amount and improving quality of the tests.

@BenjaminPaap this is an attempt to consolidate the different repositories and bring them back together. It is not intended to be the one and only solution, but it can.

@ianare does a future maintainer of this code have to care about the package prefix ? should it be renamed to something different ?

If desired I can create an organisation for this and care about the access. But first please, hands up about the suggestions from @BenjaminPaap https://github.com/digitick/php-sepa-xml/issues/53#issuecomment-63985644

/cc @naitsirch @danielmf @shad0w-rep @omigo

[BenjaminPaap]

I think the prefix should stay as it is currently @monofone. I don't like the idea of having to refactor my current working production code just because of a naming thing.

And of course thanks for investing time to merge some commits from others. I would prefer to take your repository then and just add an organization to it.

[persteinhorst]

Thank you for your affords.

The new repository from @monofone seems to work as expected in my test enviroment.

I would vote for your new repository. I think the prefix should change if there is going to be a new organisation, maybe there could be a branch with the old prefix for compatibility reasons which is maintained for a limited time only. There could be confusion otherwise i think.

[monofone]

The Prefix I mentioned was only about the composer package, by the replace configuration in the composer.json it is possible to replace the package without breaking old code. Replacing the NamespacePrefix I think is not the way to go as this will break existing production code and it will become even more difficult to bring back together the development of this library.

As company name I would suggest php-sepa-xml.

[BenjaminPaap]

+1 for php-sepa-xml as organization name

[monofone]

Ok, here we go, https://github.com/php-sepa-xml is the new home of ongoing development for this. @ianare would you be so kind and update the origins for this package at packagist or give @BenjaminPaap and me access as maintainers ?

[stollr]

Thanks for bringing up this issue and your efforts. Good to know that this lib will be managed again in the future! I have stared it already ;-)

[ianare]

@monofone, @BenjaminPaap: I've added you as maintainers to the packagist and updated the origin.

[Nguimjeu]

@monofone and the other guys: Much appreciated!