6 ms·

>Now I felt even more excited. I could push fixes and refactors without having to wait for someone to code review them. Am I the only one feeling uneasy about

by danslo 5y ago

>Now I felt even more excited. I could push fixes and refactors without having to wait for someone to code review them. Am I the only one feeling uneasy about this?

capableweb 5y ago
Yes and no. Open source is built on trust, something we're starting to feel the backsides of today, where npm modules sometimes gets compromised, but people also get shared responsibility over shared resources like reusable libraries. I'm torn if it's good or bad really. I feel like our tools should do more to protect us, but until we get there, maybe we do need to be more careful with who we're giving our trust to?
- MeinBlutIstBlau 5y ago
  From a security standpoint, how did NPM become a thing? Bar none, it feels like the most compromisable system short of SCADA.
  - easterncalculus 5y ago
    A small Javascript standard library and more demand for packages with the use cases from running it server-side seem to be contributing factors.
belter 5y ago
For users of the NPM ecosystem this must be as exciting as this bus voyage: https://youtu.be/2WP5HfRt2Us https://youtu.be/2WP5HfRt2Us
schneems 5y ago
I am very permissive at giving commit but not release privileges. I feel that’s the best value for removing blockers to contribution but still retaining some measure of control over security and quality.
- hboon 5y ago
  I'm not arguing to have code reviews for every commit (or PR). If there's no review with each incremental change, is it still feasible to review at release time?
bibabaloo 5y ago
> Am I the only one feeling uneasy about this? Why does this make you feel uneasy? Who's to say the original creator of the repo has any better intentions than the author of this article?
- alisonkisk 5y ago
  It shows that the author is unconcerned about code quality in someone else's project. But you are right that the original project had the same problem of lack of review. This is a big problem in sole author open source; such projects tend to be poorly documented, have a lot of nasty code that is error prone and hard to maintain and continued fixes to. I know this from bugfix commits I've made to various project.
mparnisari 5y ago
Hi, author here. The original author of the repo gave me permissions to push because he didn't have time to maintain it.
jillesvangurp 5y ago
There is a lot of unmaintained code out there. When somebody steps up and starts doing meaningful work to fix that, stepping out of the way and letting them do their thing is a very appropriate way to get the changes out to users. Ultimately open source is based on trust. Code reviews are nice if you can get them but github is full of projects with pull requests that aren't getting reviewed. That's frustrating for contributors and users. I tend to feel bad when somebody submits a pull request to one of my projects and I don't have time to properly review it. It happens sometimes. But I tend to bias towards merging the work unless I see something really wrong with such pull requests in which case, I'll inform the contributor. Ultimately, OSS should be a meritocracy. People doing the work gain power and trust. Nothing wrong with that.

by danslo 5y ago

>Now I felt even more excited. I could push fixes and refactors without having to wait for someone to code review them. Am I the only one feeling uneasy about this?

capableweb 5y ago

Yes and no. Open source is built on trust, something we're starting to feel the backsides of today, where npm modules sometimes gets compromised, but people also get shared responsibility over shared resources like reusable libraries. I'm torn if it's good or bad really. I feel like our tools should do more to protect us, but until we get there, maybe we do need to be more careful with who we're giving our trust to?

MeinBlutIstBlau 5y ago
From a security standpoint, how did NPM become a thing? Bar none, it feels like the most compromisable system short of SCADA.
- easterncalculus 5y ago
  A small Javascript standard library and more demand for packages with the use cases from running it server-side seem to be contributing factors.

belter 5y ago

For users of the NPM ecosystem this must be as exciting as this bus voyage: https://youtu.be/2WP5HfRt2Us https://youtu.be/2WP5HfRt2Us

schneems 5y ago

I am very permissive at giving commit but not release privileges. I feel that’s the best value for removing blockers to contribution but still retaining some measure of control over security and quality.

hboon 5y ago
I'm not arguing to have code reviews for every commit (or PR). If there's no review with each incremental change, is it still feasible to review at release time?

bibabaloo 5y ago

> Am I the only one feeling uneasy about this? Why does this make you feel uneasy? Who's to say the original creator of the repo has any better intentions than the author of this article?

alisonkisk 5y ago
It shows that the author is unconcerned about code quality in someone else's project. But you are right that the original project had the same problem of lack of review. This is a big problem in sole author open source; such projects tend to be poorly documented, have a lot of nasty code that is error prone and hard to maintain and continued fixes to. I know this from bugfix commits I've made to various project.

mparnisari 5y ago

Hi, author here. The original author of the repo gave me permissions to push because he didn't have time to maintain it.

jillesvangurp 5y ago

There is a lot of unmaintained code out there. When somebody steps up and starts doing meaningful work to fix that, stepping out of the way and letting them do their thing is a very appropriate way to get the changes out to users. Ultimately open source is based on trust. Code reviews are nice if you can get them but github is full of projects with pull requests that aren't getting reviewed. That's frustrating for contributors and users. I tend to feel bad when somebody submits a pull request to one of my projects and I don't have time to properly review it. It happens sometimes. But I tend to bias towards merging the work unless I see something really wrong with such pull requests in which case, I'll inform the contributor. Ultimately, OSS should be a meritocracy. People doing the work gain power and trust. Nothing wrong with that.