Are this project in a oficial code freeze?

[loverajoel]

There are a lot of good pull requests and nobody are reviewing/merging it about 1 month ago.
Are this project in a oficial code freeze?

[dougmoscrop]

This ^^

I'd be interested in helping maintain if there's a need

[pratik60]

+1 ?

And code freeze is not understandable, as ui-select2 deprecated to point to this. At least, merge the good pull requests....

[brianfeister]

I can't promise to add anyone as a maintainer right now. But if people could use this thread as a way of listing the good PRs you're talking about (need to have unit tests) that would be a good start. I will admit that one problem is we've reached a critical level of complexity and new features are a concern at this point. But yes, bugfoxes with appropriate tests should be reviewed and merged. Help me with a list and I'll look closer. Thank you!

[brianfeister]

Bugfoxes... Definitely a new word we need in software development.

[brianfeister]

I guess I'm waxing poetic now, I think the reason that new features are something less enthusiastically welcomed is because most of the bigger features merged in the past year have yielded serious bugs for quite a number of things for people already using the project. Each time a new maintainer comes on, even more stuff gets broken because they tend to underestimate the complexity when reviewing incoming pull requests that don't account for some edge case or another.

[dougmoscrop]

It sounds like it needs some kind of plugin architecture? I'm mostly interested in bugfixes as well as accessibility (which is basically the same thing).

If you really do mean critical mass, then maybe it's time for a ui-combobox project to take lessons learned and reapply again...

[dougmoscrop]

Also it seems like if you had someone you can trust to tag PRs effectively you could use GitHub to manage "things to merge" (vs. some ad hoc list here)

[brianfeister]

@dougmoscrop the issue of decoupling the code has already been on the books for a long time (see #402), this is ALOT of time to invest. Angular has a built-in plugin architecture via it's DI and directives, so we wouldn't need to re-invent the wheel with a plugin architecture, just break out the business logic and create alot more internally used directives than we currently have. Whoever does this work will certainly be added as a maintainer on this project, so you can consider that an invitation. I'm just unclear as to whether or not you're volunteering to do the work to convert it.

Please note as well, that this project will most likely die with Angular 2 because ngMaterial is already doing most of what this module does. ngMaterial has been slated as one of the highest priority items to convert to Angular 2 when the time comes, and they have a large team so I would not expect to compete with them with this small project. In fact, one of the reasons I'm less active on this project is because at my day job I decided to be an early ngMaterial adopter.

[brianfeister]

Also @douglasduteil, skipping the issue of a larger scale modularity refactor, let's get a feel for working together before I give you full access to merge and push code. Please go ahead and jump on open PR's that appear valuable and well-thought and just tag me and @dimirc for review. It's true that I've not been watching as I should due to the fact I'm not using the project actively anywhere. After we've had some meaningful conversations about the project and you're in the groove, we could add you as a maintainer.

[pratik60]

@brianfeister - Thanks for the response. :-)

Thinking of switching to ngMaterial as well, but waiting for v1.0 where md-chips (currently buggy) and md-table(in the pipeline) are in working condition.

[dougmoscrop]

@brianfeister I'm not sure I see ngMaterial as something that is going to render libraries like this one irrelevant, not everyone is crazy about material design nor believes in its staying power, so while ngMaterial is totally great if that's your thing, this could still be too (or whatever comes next).. also ngMaterial seems to be one big package, not sure of what their plans are there.

for sure, I don't expect to be handed the keys. I'll see what I can do.

[brianfeister]

Fair point, I guess the way I see it, ngMaterial will gain lots of popularity at the same time that Angular2 does. I agree that many developers will linger on 1.x because of the migration pain. I think a better way to look at it is that ngMaterial will gradually become the defacto standard for UI, eventually dethroning ui-bootstrap.

[RonaldTreur]

I'd like to second the fact that not everyone is going to Material way. I'm actually kinda surprised that sentiment exists at all. Plenty of interfaces will still be built on top of Bootstrap or simply on top of a custom UI-design. Just recently I created a custom theme for ui.select to be able to use it on a large corporation's website.

[AdamAxtmann]

@brianfeister I've noticed you've started assigning yourself to pull requests, but you seem to be doing so LIFO. #772 was posted back in March, @dimirc made a suggestion, I fixed it, and it's stagnated ever since. It would be nice to get some attention to requests that have been sitting for a long time.

[MikeMatusz]

Material Design's tagging isn't bad, but support for multi-select is pretty limited, especially in terms of keyboard usability. The Select2 style multi-select in this project is far superior. If you set multiple="true" on their select control and try to use it without a mouse/touch, it's very hard to do.

[timcosta]

FWIW, #1016 is a pretty serious bug affecting chrome and safari. The associated PR should be accepted.

[cdjackson]

#1108 #1096

[jnelson]

PR plug: As a lifecycle hook, an onBeforeSelect callback like #1075 might help enable moving some of that complexity out of the core. It looks like it's been included (with I think at least one nice mod) in @cdjackson's refactor branch in the relevant function.
If my approach with #1075 is acceptable, I'd be happy to add a similar onBeforeRemove to complete the lifecycle hook collection.

[cdjackson]

Your approach looked good :) I used a similar approach already for onBeforeRemove, and also another couple of hooks (open/close dropdown, and also a keypress call).

As per my comments in the other issues, I think this repo needs an overhaul - there's just too many open PRs and issues to be able to sensibly recover and many can not be merged anyway...

[ProLoser]

@cdjackson @jnelson do you guys want to just push out your refactor as a newer version?

[jnelson]

@ProLoser If @cdjackson is up for taking the lead, I'm happy to assist.

[wesleycho]

Going to close this since there are some new maintainers involved - this library could use a lot of love, so any help people are able to lend in verifying whether something is an issue and creating Plunker reproductions for them (or rejections), would be very helpful to all I think.

Currently the maintainers are @user378230 and @aaronroberson , and I'm just currently going through all the issues/PRs and doing basic triaging/review to help simplify the task for those who possess more expertise.