Interacting with maintainers should be human​ When it comes to interacting with the project — PR descriptions, code review replies, issue comments, and discussion threads — we expect to interact with real humans, not with AI-generated replies. Please do not: Paste a reviewer's comment back into an AI and post the raw output as your reply. Generate issue or PR descriptions wholesale from AI without reading and editing them yourself. Use AI to argue with maintainers on your behalf. Maintainer bandwidth is limited, and the conversation around a change is where most of the value of code review lives. If that conversation is between an AI on one side and a human on the other, it stops being useful.

Thank you for the additional clarification and for the considerable expenditure of explanatory effort represented by the preceding response. Before proceeding further with the underlying technical question, it may be useful to establish a more explicit shared understanding concerning the relationship between the quantity of information supplied, the extent to which that information is necessary for the immediate decision being made, and the finite amount of maintainer attention available for converting the supplied information into an actionable conclusion. For the avoidance of doubt, the concern being raised here is not that factual accuracy, reproducibility, technical precision, correction of earlier assertions, or sufficient evidentiary support are undesirable. Each of those properties is useful and may, under the appropriate circumstances, be necessary. The difficulty arises when the information required to establish the relevant fact is accompanied by additional explanation whose presence, although potentially interesting and perhaps even technically correct, does not materially alter the fact itself, the confidence with which that fact can be evaluated, or the action that follows from accepting it. Every response imposes what might be described as a comprehension obligation upon its recipients. That obligation consists not merely of reading the words presented, but also of determining which statements constitute factual claims, which function as evidence, which are qualifications, which are conjectures, which supersede earlier statements, which merely restate conclusions already established elsewhere, and which are included primarily to explain the circumstances under which some other statement came to be made. The cost of satisfying this obligation tends to increase with the length, density, and structural complexity of the response, even where the amount of information capable of changing the maintainer’s eventual decision remains constant. This consideration is particularly significant in the context of open-source maintenance, where the time required to read, classify, verify, and contextualize one response cannot simultaneously be used to reproduce another issue, review a pull request, investigate a regression, prepare a release, answer another contributor, evaluate a dependency update, improve documentation, or perform any of the numerous other activities competing for the same limited pool of attention. Consequently, verbosity is not entirely without cost merely because the information is supplied voluntarily, constructively, and with the intention of preventing misunderstanding. Its cost is transferred to each recipient who must determine which portions are operationally necessary and which portions can be disregarded without compromising the validity of the resulting conclusion. We would therefore ask that future responses be prepared according to something approximating a principle of minimum sufficient communication, by which a response contains the smallest collection of independently useful facts required to answer the question currently being asked or to establish the behavior currently under discussion. Information should not be included solely because it is adjacent to the subject, because it records the path by which a conclusion was reached, because it anticipates questions that have not yet been asked, because it exhaustively delineates the boundaries of claims whose ordinary interpretation is already sufficiently narrow, or because omitting it might leave some peripheral aspect of the subject less than comprehensively characterized. The use of the word “smallest” in this context should not be interpreted as a request for artificial abbreviation, unexplained assertions, incomplete reproduction instructions, or the omission of facts required to distinguish the reported behavior from another superficially similar behavior. It means, instead, that each sentence should justify the attention required to process it by contributing something without which a maintainer would be materially less able to verify the report or determine the appropriate next action. Where the removal of a sentence would leave the actionable meaning unchanged, that sentence should generally be presumed removable. Where several paragraphs can be replaced by a single concrete observation without sacrificing reproducibility, the concrete observation should be preferred. Where a mechanism can be demonstrated through a minimal configuration change and an immediately observable result, that demonstration should ordinarily take precedence over a comprehensive narrative describing the mechanism’s provenance, implications, surrounding implementation details, and hypothetical manifestations in configurations not yet tested. Qualifications should similarly be restricted to those that alter the reasonable interpretation of the principal claim. It is generally unnecessary to enumerate every proposition that is not being asserted, every environment that has not been tested, every alternative explanation that was considered and rejected, every inference that a sufficiently careful reader might otherwise draw, or every reason the author has for believing that an untested configuration may behave similarly. Where uncertainty is relevant, it is usually sufficient to identify the precise boundary of verification rather than narrating the broader epistemological status of all related propositions. One potentially useful standard for deciding whether information warrants inclusion is to ask whether the behavior that actually occurs, the smallest reliable procedure that causes it to occur, and any qualification without which those statements would become materially misleading remain understandable and reproducible after the information is removed. If they do, the removed material was probably not necessary for the immediate response. Background already available elsewhere in the issue, detailed explanations of standard language or bundler behavior, speculative generalizations beyond the verified reproducer, extended discussion of why an earlier reproducer was inadequate, descriptions of investigative paths that did not produce the final result, and multiple reformulations of the same conclusion at successively different levels of abstraction should normally be retained by the author unless and until a maintainer requests them. This request is not intended as a judgment concerning the effort, competence, thoroughness, or good faith involved in preparing the response. It concerns the format in which the result of that effort is presented. A technically correct response may nevertheless be disproportionately expensive to consume, in much the same way that a comprehensive diagnostic log may contain the relevant error while simultaneously making that error more difficult to locate. The objective is not to minimize the amount of investigation performed by the reporter, but to minimize the portion of that investigation which every subsequent reader must reconstruct before reaching the actionable result. We recognize that determining what is essential requires judgment and that contributors cannot invariably know in advance which detail a maintainer will consider relevant. In such circumstances, the preferred strategy is progressive disclosure, under which the shortest adequately supported factual answer is provided initially and further supporting detail is supplied only when a maintainer identifies a concrete need for it. It is substantially easier for a maintainer to request one missing fact than it is for multiple maintainers to independently identify and disregard several pages of facts that do not affect the decision being made. The appropriate optimization target is therefore not maximum completeness at the time of the first response, but minimum aggregate effort across all participants required to reach a sufficiently supported conclusion. A concise response that results in one targeted follow-up question may satisfy that target more effectively than an exhaustive response which attempts to preempt every conceivable follow-up but requires substantially greater processing time from every reader, including readers for whom most of the anticipated questions would never have arisen. Facts directly necessary to establish the reported behavior should be included. Evidence directly necessary to verify those facts should be included only to the extent that verification would otherwise be impractical or ambiguous. Context that may be interesting but does not change the facts, their verification, or the resulting action should be omitted unless specifically requested. Where several formulations communicate materially identical information, the shortest formulation should be selected. Where a direct statement is available, it should take precedence over a narrative account of how the statement was discovered. Where one verified claim is sufficient, it should not be surrounded by multiple hypothetical extensions. Where the answer to a question can be expressed as a concrete condition and an observable consequence, the response should ordinarily contain that condition and consequence without attempting to supply a general theory of every adjacent failure mode. It is also important to clarify that this does not mean providing a concise summary followed by the same extended explanation that the summary was intended to replace. The continued presence of the explanation preserves most of the reading, classification, and triage cost. A summary is not a substitute for removing unnecessary material when the unnecessary material remains directly beneath it. Supporting details can remain available to the author and can be supplied in a subsequent response if a maintainer determines that the initial facts are insufficient. Nor is it generally necessary to surround relevant facts with introductory courtesies, repeated apologies, rhetorical transitions, anticipatory defenses, summaries of prior misunderstandings, explanations of why the current answer differs from a previous answer, assurances about claims that are not being made, or concluding restatements of conclusions already expressed. Courtesy is appreciated, but its communicative footprint need not substantially exceed that of the technical substance. A correction is most useful when it makes the corrected claim immediately identifiable and permits the obsolete claim to be discarded without requiring the reader to reconstruct the entire history of the correction. Applied to the present exchange, the information that appears most capable of affecting maintainer action is that disabling HMR removes the React refresh preamble, that the resulting client bootstrap no longer causes the relevant environment initialization to occur before createClientRpc is evaluated, and that server-function construction consequently encounters a ReferenceError because process is unavailable. The precise import-order mechanics, the contrast with the initial theory concerning a relative URL, the implications for other plugins whose preambles may differ, the explanation of why the originally linked example does not exhibit the behavior under its default configuration, and the broader characterization of the problem as a dependency on an incidental ordering guarantee may become relevant during implementation, but they need not all be transmitted before maintainers have had an opportunity to evaluate the narrower verified condition and its immediate consequence. In consideration of the asymmetry between the effort required for an author to preserve additional material and the cumulative effort required for every recipient to inspect and classify that material, and with due regard for the limited and nonrenewable character of volunteer maintainer attention as it relates to the substantially renewable supply of potentially relevant contextual exposition, future participation would be most effective if each response were reduced, before submission, to only those empirically established statements whose omission would prevent reproduction, materially distort the reported behavior, or leave the specific question under consideration unanswered, with all supplementary narrative, speculative extension, duplicative reformulation, historical reconstruction, rhetorical cushioning, and otherwise nonessential elaboration withheld pending an explicit indication that its disclosure is required.

I was pretty burned out on just the whole... I just want my time at night back, because I have a full-time job, too.

Yeah, I think it's just the loneliness problem. I think there was almost such a point where the thought of having 3,000 users or 800 - I just literally cannot support that by myself.

At the same time, every change that enters Ladybird becomes our responsibility. It has to fit the architecture, survive future refactoring, interact correctly with the rest of the browser, and be understood by the people maintaining it. Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.

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.