Forrest L Norvell othiym23 Ellation / Crunchyroll / VRV San Francisco Wannabe JavaScript daimyo.

othiym23/async-listener 162

polyfill version of the 0.11 version of the asyncListener API

othiym23/bug-clinic 151

a workshopper for learning how to debug Node.js apps

npm/cmd-shim 50

The cmd-shim used in npm

ForbesLindesay-Unmaintained/tar-pack 34

Package and un-package modules of some sort (oooh, perhaps you could package JavaScript modules on npm...)

mikeal/nodeconf2013 31

NodeConf 2013 Planning and Sessions

othiym23/cls-middleware 19

Connect & Restify middleware to bind routes to continuation-local storage

mikeal/nodeconf2014 8

NodeConf 2014 Organizing and Planning.

dshaw/node-error-handling 5

Node Error Handing Mini Summit

issue commentnodejs/TSC

Executive summary: Introducing a CLS-like API to Node.js core

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 async-listener and continuation-local-storage. @trevnorris, meanwhile, implemented AsyncResource, and then he and others worked on what became the current async_hooks API.

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 AsyncLocal and 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

create barnchothiym23/dear-github-2.0

branch : othiym23-is-a-signatory

created branch time in 3 months

fork othiym23/dear-github-2.0

📨 An open letter to GitHub from the maintainers of open source projects

fork in 3 months

issue commentnodejs/TSC

Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-12-04

@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

issue commentnodejs/TSC

Maintenance of the bundled package manager

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

issue commentnodejs/TSC

Maintenance of the bundled package manager

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.

With that said, I don't believe this is a good forum for this discussion. While npm is bundled in official Node.js distributions, and while the Node.js project has a duty of care to its users that it be fit for purpose which extends to the things that it bundles, npm is in all other ways an independent project with its own governance, roadmap, priorities, and problems. I believe that the goal of the team working on the CLI is the same that it has always been, which is to make sure that the users of the npm CLI have as smooth and unsurprising experience when installing JavaScript packages as is practicable. I also believe that the size of the team (still very small) is vastly outstripped by the scale and level of expectation on the part of its user community (huge).

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

issue commentnodejs/admin

Moderation team recertification

I am interested in continuing to serve on the moderation team.


comment created time in 6 months