Contribute (with a P.S. of are you crazy)

[alerque]

Sure lets try.

I'm open to something in Rust, Lua, or shell related.

P.S. My experience in almost 3 decades of coding is that the first 15 minutes are often the least productive. It takes at least that long to come up to speed with what an issue even is on a project I wrote, much less somebody else's work. Sometimes the first stabs at work are actually regressions, not progress. I don't believe 15 minute work segments with a new contributor each time is going to get anywhere, but I'm open to having my mind changed.

[mmulet]

Your first rust task is here: https://github.com/code-relay-io/joshuto

I actually mostly agree with you and have those same concerns. So here is my perspective:
Programming is fun, collaboration is work.
So, I want to make a way for people to collaborate on open source projects, without it becoming work. So maybe I should change my pitch from Program in 15 minute chunks to: Program for 15 minutes or longer, then pass it off the the next person as soon as you get bored?
Code Relay's main appeal is an inverse of responsibility. In the normal fork-pull-request workflow, like a job, you become responsible for the issue and the code that solves it. You have to look into the issue, then find a fix, then someone reviews it, you have to change the style, or fix this or or that. Then, if you're lucky they merge the request, sometimes they don't.
With Code Relay, you get-in, and get-out, you are not responsible for anything more than a small part. To me, this is fun. This is what I want. I want to sit at my desk, press a button, get something to fix, work for a bit, then go on my way. A fire and forget approach. I made Code Relay to scratch my own itch, and if other people really like it, that's great. If not, I'm not afraid of failing.

[alerque]

Status

Status PR opened but upstream issue is closed and this whole task was a goose chase.

Code Relay comments

• Issues need to be better triaged before assignment. Issue triage is a super valuable part of any FOSS project, and undervalued. I do believe this is something that the wider community can contribute towards, but it's much harder to do than just biting off a problem and going to town on it. Issue triage requires considerable knowledge about both the current workings and development roadmap for a project. Realistically maintainers or active users will have a much better idea how to triage issues than random Joe that parachutes in for 15 minutes of fame. It took me a couple hours to...

  a) Get the project running and poke around enough that I understood what it did and could use it well enough to test the issue.
  b) Familiarize myself with the current implementation to know what libraries were in use and whether there was anything relevant to the current issue (there was, an existing depreciate() mechanism was already in place).
  c) Look around the Rust ecosystem for alternative implementation ideas and whether any of them applied at all.
  d) Write up my findings in a way that any logical next step could be taken.

  Realistically if I'd stopped anywhere short of those steps everything I'd done to that point would have gone to waste. My 15 minutes, 30 minutes, 45 minutes, 1 hour 30 minutes etc. all had virtually nothing to report. It wasn't until nearly 2 hours in that I could reasonable make the determination that there didn't seem to be an actual problem to solve.

  A project maintainer or active user would probably have been able to come to the same conclusion in about 5 minutes, just as I might be able to for one of my own projects or something I use actively.

  If contributions are going to be effective in smaller chunks, the chunks need to be managed a bit better. First triage issues, then task them. At the very least I would prioritize upstream projects that have done some initial triage and marked issues as pr-accepted or help-wanted or crio-approved or something. An upstream maintainer that has suggested an issue might be valid for a new contributor to work on and that a contribution would be accepted makes issues much more likely to succeed.

• I'm already a very active FOSS contributor, and I constantly have more urge to dig in and contribute than I do time to make it happen. Even with that background I struggled for motivation on this one. The two things that kept me going we an interest in learning Rust better through exposure to more projects and solutions and curiosity on how this relay idea would work out. Otherwise being assigned to some random project that I'd never heard of and don't plan to use going forward was kind of uninspiring. There are so many FOSS projects I do use and would love to improve that it felt kind of weird to be off scratching somebody else's itch. Maybe I'm not a good candidate for code relay, but I honestly think this is a serious weak point in the concept. I'm not sure what to do about this, but maybe having a selection process where contributors are matched to 3 or 4 choices of issues rather than just 1 might raise the interest level and hence the motivation to finish.

  1. Pick a language (15-20 possible scopes)
  2. Pick a project (suggest 2 or 3 projects in the selected language)
  3. Pick an issue (suggest 2 options or pre-approved issues in the selected project)

  Keeping the list of choices very small and wording them carefully would both make the process approachable and point them towards a better match. "What language are you most interested in working with?" "Which of these two projects sounds most interesting to you?" "Which of these two issues sounds like something you could tackle?"

• The current work flow is both cumbersome and undocumented. Forking a project, editing the readme, PRs to the fork but reading upstream issues ... this is a tangled mess and I'm not even sure what the plan would be if something got done. Were you going to then collect all the bits, rebase them to remove the comments, match upstream commit guidelines, then PR the result to the upstream?

  I realize GitHub isn't setup for the workflow you have in mind, but I'm almost certain we could come up with something better. If I had any faith in the rest of the project I'd start suggesting some, but at this point I'm unconvinced.

If any of these merit further discussion I can copy them to new issues or to discussions if you enable that feature on this repo.