5 ms·

I'm not sure if this is really true. Why would you want to become a contributor to an OSS project if you can't bother to get it working on your machine? You act

I'm not sure if this is really true. Why would you want to become a contributor to an OSS project if you can't bother to get it working on your machine? You actually learn quite a bit about the project by going through its dependency hell.

aerovistae 6y ago
Idk, I feel like we've been trained to believe this is necessary. Why you should need to know more about a dependency than its documented API? This sort of reminds me of Americans believing their current healthcare situation is the only way to do it even though it's awful.
- marceloabsousa 6y ago
  Don't get me wrong - I don't think that you should go through it every time. Also, I'm not sure anyone reads the documented API of a dependency until some unexpected behaviour is happening. My basic point is that the dependency hell is not the biggest barrier for an open source contribution. In fact, mixing both problems is a bit strange to me - codespaces is not going to magically solve the dependency hell - it's just going to shift it to some other part of the configuration. The best way to start contributing to an OSS project is really be to have a mentor in project who could guide you through it during your first contribution. Personally, I'm willing to fight the machine for a couple of hours/days to get something to compile -- however, it's hard to justify reading code for weeks in the hope I can tackle an open issue.
- ehsankia 6y ago
  Sometimes setup on different platforms is different in very subtle and hard to debug ways, and for smaller OSS projects that haven't yet been tested on different platforms, it may be very hard to figure that out. Now you can develop even on a chromebook (without the terminal access) without having to deal with any of that.
cachestash 6y ago
The only time I could see myself using this is in the following scenario; 1. Browsing repos. 2. See a quick fix I could make (like a typo) 3. Open up the code space view, make the change, add and commit it. For my daily needs I would never replace an online IDE with my local IDE. I see no value in doing that. My concern would be for when github has a service outage. I am without my IDE until they resolve the issue? With a local IDE I can just continue to work on my branch and push it when GH comes back online.
- MauranKilom 6y ago
  > The only time I could see myself using this is in the following scenario You can already do this. There's an edit button when you view any file and a streamlined process for turning your change into a PR. I don't think Codespaces will make this any faster. Maybe you can fix slightly less trivial things due to the IDE support but on the level you described no new capabilities are added.
  - radus 6y ago
    I think with the same editor experience as I use on my own machine, I can fix substantially more complicated issues, with significantly less effort.
seph-reed 6y ago
I'd like to be able to contribute to Firefox or Brave, but there's no way I'm going through with the setup. If I could just do some small stuff, maybe write some unit tests, that would be fine.
- marceloabsousa 6y ago
  If going through the setup is hell, what makes you believe that it'll be easier to contribute after you get it for free? I still believe the best way is for OSS projects to ask contributors to do some mentoring...
  - seph-reed 6y ago
    > what makes you believe that it'll be easier to contribute after you get it [setup] for free I'm flabbergasted. Like.. I don't even know where to start. You've been through an on-boarding process before right? Have you led one? Haven't you ever watched a junior dev get dragged through all sorts of arbitrary "don't breathe on it" setups just so they can start making tiny isolated bug fixes? And even then, you're just following instructions where even most high level developers don't even know why their project is set up the way it is. We've worked on very, very, very different projects your and I.
    - marceloabsousa 6y ago
      I don't understand what your comment have to do with contributing to OSS. Anyway, I don't really believe that codespaces or any out of the box tool is going to be a magical solution for junior devs not be dragged in those kind of setups in the projects that you're referring to.
      - seph-reed 6y ago
        > magical solution for junior devs not be dragged in those kind of setups in the projects that you're referring to That's exactly what this is. The setup is part of a clonable environment. So for large scale compiled projects, you wouldn't have to: 1. Download the massive thing 2. Get it to compile 3. Potentially not have to compile many files that already have their `*.o` (or equivalent) file in the environment. It could be like just walking up to some other developers fully functioning station, and getting started.
petetnt 6y ago
I contribute to various OSS (and private) projects all time just by using the GitHub code editor and catching errors or regressions if any in the CI. Having a fully fledged dev environment is even better.
- marceloabsousa 6y ago
  This is pretty cool. Can you share a bit more about your experience? I would like to be able to help out this way.
  - petetnt 6y ago
    Basically it's just the same as whipping out a simple text editor in hurry; if I need to modify multiple files, I just do multiple commits (do a change -> commit -> jump to my branch/fork -> do the rest of the changes one by one) as GitHub doesn't support editing multiple files for a single commit and then I wait for the CI results. If something goes awry I'll probably clone the repo at that point.
alkonaut 6y ago
Most of the time when I contribute to a GH project it works like this: I use the product, discover a bug, search on their GH, don’t find it, file a new bug report, clone the source fix the bug, submit PR, never commit to the same project again. The threshold for doing that sort of minor work can be lowered a lot by this.

aerovistae 6y ago

Idk, I feel like we've been trained to believe this is necessary. Why you should need to know more about a dependency than its documented API? This sort of reminds me of Americans believing their current healthcare situation is the only way to do it even though it's awful.

marceloabsousa 6y ago
Don't get me wrong - I don't think that you should go through it every time. Also, I'm not sure anyone reads the documented API of a dependency until some unexpected behaviour is happening. My basic point is that the dependency hell is not the biggest barrier for an open source contribution. In fact, mixing both problems is a bit strange to me - codespaces is not going to magically solve the dependency hell - it's just going to shift it to some other part of the configuration. The best way to start contributing to an OSS project is really be to have a mentor in project who could guide you through it during your first contribution. Personally, I'm willing to fight the machine for a couple of hours/days to get something to compile -- however, it's hard to justify reading code for weeks in the hope I can tackle an open issue.
ehsankia 6y ago
Sometimes setup on different platforms is different in very subtle and hard to debug ways, and for smaller OSS projects that haven't yet been tested on different platforms, it may be very hard to figure that out. Now you can develop even on a chromebook (without the terminal access) without having to deal with any of that.

cachestash 6y ago

The only time I could see myself using this is in the following scenario; 1. Browsing repos. 2. See a quick fix I could make (like a typo) 3. Open up the code space view, make the change, add and commit it. For my daily needs I would never replace an online IDE with my local IDE. I see no value in doing that. My concern would be for when github has a service outage. I am without my IDE until they resolve the issue? With a local IDE I can just continue to work on my branch and push it when GH comes back online.

MauranKilom 6y ago
> The only time I could see myself using this is in the following scenario You can already do this. There's an edit button when you view any file and a streamlined process for turning your change into a PR. I don't think Codespaces will make this any faster. Maybe you can fix slightly less trivial things due to the IDE support but on the level you described no new capabilities are added.
- radus 6y ago
  I think with the same editor experience as I use on my own machine, I can fix substantially more complicated issues, with significantly less effort.

seph-reed 6y ago

I'd like to be able to contribute to Firefox or Brave, but there's no way I'm going through with the setup. If I could just do some small stuff, maybe write some unit tests, that would be fine.

marceloabsousa 6y ago
If going through the setup is hell, what makes you believe that it'll be easier to contribute after you get it for free? I still believe the best way is for OSS projects to ask contributors to do some mentoring...
- seph-reed 6y ago
  > what makes you believe that it'll be easier to contribute after you get it [setup] for free I'm flabbergasted. Like.. I don't even know where to start. You've been through an on-boarding process before right? Have you led one? Haven't you ever watched a junior dev get dragged through all sorts of arbitrary "don't breathe on it" setups just so they can start making tiny isolated bug fixes? And even then, you're just following instructions where even most high level developers don't even know why their project is set up the way it is. We've worked on very, very, very different projects your and I.
  - marceloabsousa 6y ago
    I don't understand what your comment have to do with contributing to OSS. Anyway, I don't really believe that codespaces or any out of the box tool is going to be a magical solution for junior devs not be dragged in those kind of setups in the projects that you're referring to.
    - seph-reed 6y ago
      > magical solution for junior devs not be dragged in those kind of setups in the projects that you're referring to That's exactly what this is. The setup is part of a clonable environment. So for large scale compiled projects, you wouldn't have to: 1. Download the massive thing 2. Get it to compile 3. Potentially not have to compile many files that already have their `*.o` (or equivalent) file in the environment. It could be like just walking up to some other developers fully functioning station, and getting started.

petetnt 6y ago

I contribute to various OSS (and private) projects all time just by using the GitHub code editor and catching errors or regressions if any in the CI. Having a fully fledged dev environment is even better.

marceloabsousa 6y ago
This is pretty cool. Can you share a bit more about your experience? I would like to be able to help out this way.
- petetnt 6y ago
  Basically it's just the same as whipping out a simple text editor in hurry; if I need to modify multiple files, I just do multiple commits (do a change -> commit -> jump to my branch/fork -> do the rest of the changes one by one) as GitHub doesn't support editing multiple files for a single commit and then I wait for the CI results. If something goes awry I'll probably clone the repo at that point.

alkonaut 6y ago

Most of the time when I contribute to a GH project it works like this: I use the product, discover a bug, search on their GH, don’t find it, file a new bug report, clone the source fix the bug, submit PR, never commit to the same project again. The threshold for doing that sort of minor work can be lowered a lot by this.