4 ms·

Exactly how does it know how to send email from the command line? I'm using gmail. Am I supposed to figure out how to configure gmail for SMTP, put the server a

by ufmace 10y ago

Exactly how does it know how to send email from the command line? I'm using gmail. Am I supposed to figure out how to configure gmail for SMTP, put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks? Or see Manishearth's comment above. Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial. Yeah, you gotta know Git, but at least Github has nice easy buttons to guide you through doing things.

carussell 10y ago
> Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy. If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site. You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change. (I've referred to this in the past as using a strategy of dark patterns inspired by social networks.) I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing. > I don't see any way for that to not be trivial Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.
- mememachine 10y ago
  It does leave a bad taste in my mouth that github is required, and they could easily do something about it. If they were open about it i probably wouldnt care, but this seems deceptive.
u801e 10y ago
> Am I supposed to figure out how to configure gmail for SMTP, Not to be condescending, but you can get the necessary information for doing that by using your favorite search engine. > put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks? You could test that by trying to telnet to the SMTP server on the ports they claim to accept connections on. ISPs may block port 25, but they usually don't block ports for secure SMTP connections (like 465 or 587). As for security tricks, you can always try sending an email to yourself or another email account for testing.
- ufmace 10y ago
  Knowledge is about how to do things. I think we both have enough to figure out how to get a task like that done. Wisdom is knowing how to choose the simplest possible way to get a job done, i.e. knowing what not to do. I have enough to know which solution I'd rather spend my time on. Do you?
  - u801e 10y ago
    I think it really comes down to the conventions of the project that you wish to contribute to. Anyone is welcome to suggest improvements to the established workflow, but it really isn't productive to rant about something that really should be a non issue.
hueving 10y ago
Have we really reached the point where developers don't understand how to setup email? If so, then you're probably right and developing via email is going to be harder for them.

by ufmace 10y ago

carussell 10y ago

> Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy. If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site. You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change. (I've referred to this in the past as using a strategy of dark patterns inspired by social networks.) I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing. > I don't see any way for that to not be trivial Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.

mememachine 10y ago
It does leave a bad taste in my mouth that github is required, and they could easily do something about it. If they were open about it i probably wouldnt care, but this seems deceptive.

u801e 10y ago

> Am I supposed to figure out how to configure gmail for SMTP, Not to be condescending, but you can get the necessary information for doing that by using your favorite search engine. > put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks? You could test that by trying to telnet to the SMTP server on the ports they claim to accept connections on. ISPs may block port 25, but they usually don't block ports for secure SMTP connections (like 465 or 587). As for security tricks, you can always try sending an email to yourself or another email account for testing.

ufmace 10y ago
Knowledge is about how to do things. I think we both have enough to figure out how to get a task like that done. Wisdom is knowing how to choose the simplest possible way to get a job done, i.e. knowing what not to do. I have enough to know which solution I'd rather spend my time on. Do you?
- u801e 10y ago
  I think it really comes down to the conventions of the project that you wish to contribute to. Anyone is welcome to suggest improvements to the established workflow, but it really isn't productive to rant about something that really should be a non issue.

hueving 10y ago

Have we really reached the point where developers don't understand how to setup email? If so, then you're probably right and developing via email is going to be harder for them.