As you all noticed I haven't given too much attention to this project in recent years, which I regret, but realistically I probably won't be the best maintainer given I haven't been using Ruby for years now, lost the contact with the ecosystem whatsoever.

Did you actually fix a known issue? Let the author know about it.

Developers want to improve their project. If you find an issue, bring it up. If it's a valid concern, the author will probably want to have it fixed. In many cases, the author will consider it a valid issue, but simply not have the personal time or need to address it immediately. This is where open-source is great. Just fork the project and fix it

Not everyone has time to adhere to the specific coding styles for a project, so if you can't do a full blown pull-request, there is NOTHING wrong with opening a pull-request that only has the intention of showing the author how you solved the problem.

On behalf of all open-source developers and project maintainers, I ask you try and be polite the next time you ask for support. Try to remember that there is a real human being on the other side of the screen, and they actually want to help you.

If you feel there has been an oversight, it's okay to not give up. As long as you are being logical and open to other people's views, you will find that you might learn something new, or even teach something to the maintainer.

(If you are a representative of an upstream for which there exists an image and you would like to get involved, please see the Maintainership section below!)

One problem with using this extension is that the author stopped supporting their extensions years ago and has not been heard from since. You also need to bypass the version check per this article.

NOTE: this repository is mostly unmaintained; I will review and merge PRs, but I(@zenhack) am no longer using this tool myself and am thus not motivated to otherwise actively develop it.

If you do not represent upstream and upstream becomes interested in maintaining the image, steps should be taken to ensure a smooth transition of image maintainership over to upstream.

I don't understand the hesitation here to accept a really useful addition to rspec. Maintenance burden. Forseen internal changes required to do it. Unforseen internal changes required to do it. Formatter changes to handle new output status for a spec that passed and failed It's simply not a previously design use case of RSpec. It will be hacky to implement.

We already have a very wide configuration API. The further we expand it the more unwieldy it becomes for users. At this point we generally require new features to be implemented first as extension gems, and then to see support, before considering including them in core.

Lately I've been much happier working with ROM, so it's just as well that Rails is obsoleting this gem.

The number of complaints across the issue tracker and the lack of substantive followup on many of those complaints should be ample evidence that these frustrated users exist and are likely about to leave Fenix behind in droves, if they haven't already.

How can we get action on the bugzilla bug mentioned above to cause this to be fixed?

Users who have installed it decided to trust me, and I'm not comfortable transferring that trust to someone else on their behalf. However, if you'd like to fork it, feel free.

I don't believe the sprockets and sprockets-rails maintainers (actually it's up to the Rails maintainers, see rails/rails#28430) currently consider it broken. (I am not a committer/maintainer on any of those projects). So there is no point in "waiting for someone else to fix" it; that is not going to happen (unless you can change their minds). You just need to figure out the right way to use sprockets 4 with rails as it is.

Rsync was originally written by Andrew Tridgell and is currently maintained by Wayne Davison.

As of May 24, 2016, antimicro has moved from https://github.com/Ryochan7/antimicro to https://github.com/AntiMicro/antimicro. Additionally, project management has passed from Travis (Ryochan7) to the AntiMicro organization due to Travis having other interests and priorities.

Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.

markdown-it is the result of the decision of the authors who contributed to 99% of the Remarkable code to move to a project with the same authorship but new leadership (Vitaly and Alex). It's not a fork.

Open a separate PR to add Rails 6 to the CI matrix

@kirs can we leave the typecast API out for now? This will conflict with the work @sgrif want to do and it would maybe make harder to integrate.

Maintaining open source software requires energy and a "want"/"passion". I've not been using this project myself for years, and I mainly work in other things than Rails at this point. That means I'm far removed from this project and see no personal gain in maintaining the energy to keep this going.

I'm still pretty proud of the project and I don't want to see it gone, so I want to keep updating it when needed. But on the other hand, the feature set is pretty stable and well working now (AFAIK) so I also don't see the need to pretend to be actively maintaining it.

Please: Prompt me when things break and I will probably fix it. I won't guarantee how fast I'll move, but I'll try to make the effort sometimes. The bigger the issue, the more likely it is that I'll do something about it.

It's not impossible, but it's not likely I would accept someone I haven't worked with IRL or know on a personal level. That's because I want some form of creative control over the direction and I want to maintain the existing code style. If I know you I'm more likely to know that this will keep working the way I want it to.

a triager would be very welcome; someone that can ask follow-up questions on issues, create test cases for the problems, and so on.

Show me good PRs, bug triaging, documentation fixes, whatever and you're a candidate if you ask for it.

I hope @hperrin you're still alive to discuss about this and eventually for a pull request.

Preview/beta release (I wish @hperrin allows it to pull request it here)

@monkeythedev I am curious how do you "organize" your work - You forked https://github.com/hperrin/svelte-material-ui and https://github.com/hperrin/svelte-material-ui is not very active. Do you plan an independent project ? I hope the original author would return at some times, if not, i'll see

I agree, it would be great to join forces and speed up development... Svelte really needs one safe material library option.

Maybe @hperrin would be able to make an appearance and select a few additional maintainers to help out.

I guess I was just waiting for some interest from a maintainer, since there's not much point in wasting my time on developing this if the maintainers aren't even interested in this feature.

Thanks for the PR @RedHatter. I think it's important to be able to specify which warnings are being disabled, and I'm nervous about the use of the code frame for this sort of thing (feels brittle), so I've opened a new PR, #3351. Will close this in favour of that

you took 4 hours to respond, so I implemented it myself

The collection of changes to fix the issues we want to address would be probably of the same size, but it would make easier to review and merge if we could break this PR in many steps. I find it really hard to believe we need to change 170 lines in a single commit to be able to fix this issue. We probably could break the first commit in many commits, test the class better and that would give more confidence over what is being changed. Right now I see a huge diff, with a few assertions changes and no real reason why all those lines had to change.

We've stated what's required multiple times now: #14540 (comment) #14540 (comment), and the follow up arguments weren't convincing. Follow Rafael's advice in new smaller PRs to advance this or it'll simply stay closed

Matz is a very busy person. Take this opportunity to ask him.

The date, time and place are scheduled according to when/where we can reserve Matz's time.

But, I was no longer using the gem, the issue activity was overwhelming, and the codebase in serious need of reworking.

There were already some second-generation maintainers on the project, but they had, apparently, burned out.

Becouse of CanCan, StateMachine and others I deside to create OpenSource organization to maintain gems. People disappear, lose their passion about coding, get new interests, families, children. But if us many we can support gems much longer. I dont pretend to be an expierenced ruby developer, but I can do administarative work: managing teams, members, approve simple pool-requests. If you think it good idea and want to support some inactive gems, not life time, maybe just a little - welcome to organization.

There's actually discussion among the rubygems team about a process for putting gems "up for adoption" that you might be interested in: http://www.benjaminfleischer.com/2014/08/17/rubygems-adoption-center/

So what will happen with these projects from now on? All of the projects above have one thing in common: they were created and maintained by passionate individuals who wanted to make positive contributions to their communities. Without these individuals and their efforts, these projects would not have become what they are today. Therefore, it is only fair that Plataformatec gives these individuals control of these projects moving forward.