Hi @jshjohnson,
my name is Christian and I鈥檓 developer for a company called @SamhammerAG from Bavaria/Germany. We use this library for about two years now. Thank鈥檚 for spending so much effort for developing, and maintaining it in the past!
We saw, that you鈥檙e searching for someone who continues to maintain this repsitory. My company decided, that we want to take over the repository to our organization account. We do not plan to actively do feature development or bugfixing for now (except for out own needs) but maintain the automation pipeline, review pull requests, do releases and so on.
Would that be ok for you?
Hi @ckotzbauer @jshjohnson ,
I am a developer at SAP and we have been using your great library for about a three years.
We have done lots of customisations to it, and also implemented a react wrapper for our needs.
I am alo interested in becoming a maintainer. As well as @ckotzbauer I can review and merge pull requests and manage new releases and also provide fixes and features that are needed for us.
Hi @MaksimShakavin
if you (and maybe others) are interested in maintaining this library too, we should move it to a own github-org for better access management instead of moving to the org of my company.
If there are any objections against the approach of transferring the ownership of this project and the strategy I suggested, please let's discuss this here and find solutions for this instead of just downvote. :wink:
I believe it's better to hold this project alive, maintain it's infrastructure, discussion process, review PRs and create new releases, instead of let it die silently...
@jshjohnson What is your opinion on this? The project should be kept alive rather than letting it die.
Hey @ckotzbauer & @MaksimShakavin, are you happy to be added as collaborators?
Hi @jshjohnson
I discussed this with my colleagues and we would still prefer a new independent github-organization. For clarification: I am not the only developer (from my company), which would be interested in maintaining this library, so I think it would be the wrong way to add single devs as collaborators... What do you think? Do you have any objections against an own community-managed org?
ping @jshjohnson
ping @jshjohnson
ping @jshjohnson, this great lib should be maintained,
Any "choices" from you ^^ ?
Just to note here:
We at @SamhammerAG are currently no longer interested to take part in maintaining this library. We discussed other possibilities for our software and will replace Choices in the near future to create a more uniform user experience with other components. The maintenance state of this library also affected this decision.
We still hope, that Choices will be maintained in the future, as it's a great library with a great user base. 馃槈
@ckotzbauer Let us know what alternatives you have found.
@stell I wrote a dependency-free Tree-Component with a colleague last year, which also has a dropdown-mode. Basically this can also be used like Choices (Tree with only one hierarchy).
https://github.com/ckotzbauer/simple-tree-component
@ckotzbauer this is a really interesting library, but this is not like Choices (not about the tree behavior of course),.
Choices keep the <select> HTML element that yours seems not. That why I choose Choices because I need to keep the element inside my DOM for my form purposes.
@ckotzbauer Looks great, but like @kl3sk said, we need form elements too.
@kl3sk @stell
Yes, my component uses a data-driven approach, where the DOM is not the leading part. Of course, if you need this, then my component is maybe not the best solution for you. But I'm always open for discussions and feedback.
But maybe not here, to avoid spamming all others in this thread 馃槅 馃槈
Hi all - sorry for the radio silence on this. I've just transfered this repo to its own organisation: https://github.com/Choices-js
If people are willing to be added to a team of maintainers in this organisation, let me know and i'll get you added
Most helpful comment
Hi @MaksimShakavin
if you (and maybe others) are interested in maintaining this library too, we should move it to a own github-org for better access management instead of moving to the org of my company.
If there are any objections against the approach of transferring the ownership of this project and the strategy I suggested, please let's discuss this here and find solutions for this instead of just downvote. :wink:
I believe it's better to hold this project alive, maintain it's infrastructure, discussion process, review PRs and create new releases, instead of let it die silently...