polyfill version of the 0.11 version of the asyncListener API
a nodeschool.io-style workshopper for learning how to debug Node.js apps
The cmd-shim used in npm
NodeConf 2013 Planning and Sessions
Connect & Restify middleware to bind routes to continuation-local storage
NodeConf 2014 Organizing and Planning.
Node Error Handing Mini Summit
When I started working on what became
continuation-local-storage – both to solve the needs of the APM vendor for whom I was working at the time and at the behest of the then-leader of the Node project – it was with the goal of having the API become a part of Node core. It was also intended to provide a minimal API surface and to try to avoid some of the mistakes we knew we had made with domains.
Several people raised concerns about introducing another abstraction as costly, in terms of implementation complexity and performance, as domains, and so @trevnorris and a few others argued successfully that this was something that should be kept in userland, and instead a lower-level API with fewer consequences be implemented in core. I still needed to ship, so I, along with @creationix and a few other people, shipped first
continuation-local-storage. @trevnorris, meanwhile, implemented
AsyncResource, and then he and others worked on what became the current
I mention this context simply to point out that I have always seen value for this functionality in core, while agreeing that end users should not bear the cost for abstractions for which they have no use. Also, I agree with the goal of creating a simple, clean abstraction that can be used for both the purposes of APM and for developers of web applications who want a hygienic way of passing state throughout a request / response cycle. I think
executionAsyncResource does expose too much internal state and should probably remain experimental. One of
AsyncContext therefore makes a lot of sense to me, but I haven't been working with APM or even Node very closely for a while, and so I don't feel qualified to weigh in on which is superior. I defer to @vdeturckheim and @Qard, but also I support their recommendations because I think their goals and approach are fundamentally identical to my own when I was working on this more actively.
comment created time in a month
PR closed othiym23/dear-github-2.0
pr closed time in 3 months
PR opened drop-ice/dear-github-2.0
pr created time in 3 months
PR opened othiym23/dear-github-2.0
pr created time in 3 months
created branch time in 3 months
📨 An open letter to GitHub from the maintainers of open source projects
fork in 3 months
@Trott One user was blocked from the organization for posting spam comments, and there is an ongoing incident where @nodejs/moderation is working with @nodejs/tsc and @nodejs/community-committee to deal with a potential Code of Conduct violation within the organization. Beyond that, the moderation team has nothing to report.
comment created time in 3 months
I have a couple brief responses to a few specific points you raise, and then I'll bow out of this discussion.
You seem defeated by the prospect of scaling an open source operation.
If npm Inc is mired in an impenetrable fog of bureaucracy or too strapped for cash to serve the community, then those are also problems that could potentially be solved by reallocation of community resources. (When I say “community resources,” I am not speaking euphemistically of the Node.js org; I am speaking more broadly, thinking of volunteers, and considering the possibility of corporate donations by those who depend on NPM.)
Consider the shading you gave this discussion, because there's a negativity and imputation of bad faith in what is quoted above that is not coming from what I wrote. If you go back and read what I said, I don't think you will find defeatism, nor a sense that the problem is one of bureaucracy.
I don't believe that the problems of managing a popular open source project are, in the end, problems of scale or the correct allocation of resources. The biggest problems are of maintaining consensus and pursuing the correct objectives. Maintaining an orientation is the hardest part of management, and this is especially true when you have a team composed of volunteers who may have very little common purpose aside from solving their own immediate problems or a broad sense of serving the community surrounding a project.
Each additional stakeholder added to a project brings with them their own goals and perspectives. Establishing and preserving consensus grows increasingly untenable as the number of participants grows, and in the absence of consensus, there must be some other means of coming to decisions if a project is to continue making progress. There will always be a core group of people who make the important decisions, and they will inevitably make decisions that displease other stakeholders. This is what it means to not have consensus, especially in the black and white world of OSS discourse, where "disagree and commit" is not really a thing.
I merely took a small sample of bad service from a big package
Your frustration is plain, so in return I will be equally blunt: npm owes you no service. npm's maintainers owe you nothing at all. You offered your contribution, and it was not taken up – any additional interpretation of what happened is simply interpretation, not a record based on actions. There is no contract or obligation, explicit or implied, governing what npm will do with community contributions, and while it would be friendly and helpful if you were given explicit feedback on why things played out the way they did, that is not something to which you, or any other participant in the community, are entitled.
comment created time in 3 months
Full disclosure: I was once employed by npm, Inc., and my duties included managing the CLI team, heading up community engagement with the CLI user base, and acting as a coordinator between npm and the Node.js Foundation. I am presently a member of the Node.js moderation team, although I don't believe it to be appropriate for me to participate in moderation of this discussion as I have an interest in it (and am now participating in it).
I am the furthest thing from a disinterested bystander, but it has been several years since I left npm, and I believe I have some distance and perspective now to match my previous level of investment. To be clear, there are points in the linked threads where you, @jacksonrayhamilton, mention me, but those points happened after I was no longer at npm, and the nature of my departure was such that it didn't make sense for me to continue to participate in the project in any form.
npm has always had unusually transparent governance. Even with all the tumult surrounding npm as a company over the last year or so, there have been several blog posts outlining the roadmap that the team is working from. npm has always had some kind of dedicated community site (whether that's Discourse or a GitHub issue tracker) for discussions, and its various maintainers have always been easily reachable on a wide variety of channels (occasionally too much so – I'm not the only npm maintainer to have been pushed deep into the red of burnout by trying to remain engaged and accessible to the broader JS community). It has a well-defined RFC process. It has a constellation of contributors who have given freely of their time and energy simply out of a desire to support the community of which they are a part.
However, as you have experienced, there are few guarantees for open source projects, even those backed by companies with a major stake in the outcome. As I mentioned above, the team is small, and time is short. Open source maintainers, particularly those of popular projects, never have enough time. Time to fix problems, but also time to share context and bring clarity to people as to why the project may or may not be adopting certain solutions or merging certain changes.
I think this is just reality, and not something that can be remediated by replacing one form of governance with another. Even if many more maintainers are added and more efficient processes are adopted to minimize overhead and ensure the timely consideration of proposed changes (or whatever weaknesses a given set of people feel should / must be addressed), somebody or some group of people still must exercise judgment and decide which changes are going in, and which aren't. And it is going to be difficult, if not impossible, for the maintainers to be able to explain their reasoning to everyone involved satisfactorily. Just keeping the team all facing the same direction is hard enough (management complexity grows combinatorily as the number of developers grows linearly), much less somehow finding the wherewithal to keep the thousands of external users aware of what the team's priorities are and why.
I'll put it plainly: there will always be situations in a project like npm where the users feel like the maintainers have dropped the ball. Sometimes that will be true, but more times there will be more going on than is immediately visible. As a potential contributor to a project with millions of other users invested in the tool meeting their own needs, you are not always going to get what you want, even if it seems like what you want is a small, self-evidently reasonable change. This is not something that can be fixed by changing who's responsible for making the decisions or reworking the process by which decisions get made; it's simply a consequence of popularity and living in a world of all-too-finite constraints. It sucks that you feel like your time and contribution weren't properly honored, but, even not being involved with npm in any capacity anymore, I feel absolutely confident in saying that there's no malice directed at you or any of the other participants in the threads to which you link by anyone on the project.
comment created time in 3 months