I talked to them about this and they said they'd work on it etc. etc. Not sure if anything has changed in that regard or not.

[0] https://github.com/streetwriters/notesnook

[1] https://developercertificate.org/

I'd really like an avenue to get into the US market as a remote worker, but am being unfairly treated by this job market. It is a pity as I am both a highly skilled programmer and have nearly a decade of experience. I'd consider this service if it could serve to showcase my skills, but if I am not going to get any credit for doing the work personally, there doesn't seem to be much point to it.

Many companies, including my own and the commercial open source companies mentioned in this post, consider open source contributions a major factor in hiring remote talent.

In your experience, is there usually a more or less deterministic path to a stage where the question of starting to get paid usually comes up? Who initiates it?

The result of this discussion may very well be that the company isn't interested in this kind of relationship for any number of good reasons. But what's important, I think, is for a contributor to be able to have the right expectations coming in. As in:

- Should I join on a purely for fun basis and see where it goes from there, keeping in mind things most likely will stay this way going forward.

- Or if everyone is happy with the quality of code, communication, etc across a number of pull requests, then it's definitely OK and expected to bring up the question of payment/employment.

Thank you.

Send a couple more high quality PRs and you can likely leverage that into a job.

There is no deterministic way to transition from unpaid to paid. It's just one signal among many that a recruiter or company looking for services would look into.

Depending on your location there may be legal restrictions preventing from US companies hiring you - even through a B2B contract.

But ultimately it depends on the motivation of the company itself, and they use all sorts of excuses to not work with non-US staff

The ones that care to hiring within vetted countries for $reasons usually will not accept exceptions. Notable example is GitHub which has a list of countries they hire from (even though they're owned by MSFT and could hire on the Moon if they wanted).

Having a company is mostly for tax purposes. It makes everything easier. I think the hiring company doesn't care if the contract is done with a business or an individual. Both are usually limited liability and offer no advantage in case of contract breaches.

In my experience as a hiring manager it was quite rare to see lots of OSS work in candidates’ GitHub accounts, but I’d absolutely prioritize those that had good work in OSS. (Also worth emphasizing that technical design, collaboration, and documentation are important and underrated, and can also be showcased in an OSS project. If you can demonstrate good communications in an async OSS environment, that would probably reflect well on your ability to contribute as a remote employee.)

All that said I’m not sure that OSS is the best resume builder. For big companies you need to drill LeetCode and system design. Perhaps for startups it is not the worst use of your time.

Exactly. Any hiring manager with a brain and not bound my clueless corporate processes would use OSS contributions are a decent signal for proficiency and social skills.

That means nothing in a big corp though. The hiring panel will never accept a candidate that fails the Leetc0d3 test because that means other panels could do the same and then it all falls apart for them. Status quo and all.

As a small company you don’t need to try to remove bias with objective metrics (indeed, “culture fit” and “thinks like me” can be good heuristics for building a small tight-knit and high-performing team) but when you hit the company size where you must introduce multiple layers of management, then fully trusting each line manager’s subjective judgements can lead to very disparate quality and other political/organizational issues.

What would be an ideal way to attribute the hard work back to the devs in our case?

I read the certificate. It isn't long:

    Developer Certificate of Origin
    Version 1.1

    Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

    Everyone is permitted to copy and distribute verbatim copies of this
    license document, but changing it is not allowed.

    Developer's Certificate of Origin 1.1
    
    By making a contribution to this project, I certify that:
    
    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or
    
    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or
    
    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.
    
    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.

(1) GitStart releases their patch under the open source license of the project's choice.

(2) An employee of GitStart submits it, in their official capacity, to the project, asserting under clause (b) that the contribution is based on (consists entirely of) previous work that is covered under an appropriate license.

   I. At least one of (a), (b), (c) is true.

  II. I understand and agree as specified in (d).

The problem lies in the definition that “committer most NOT be an organization” which would require us to do a full review of our legal contract with devs so that this condition is upheld properly

We often think of orgs as these big trusty things but honestly they are just groups of individuals, and it's harder to trust N individuals than it is to trust one individual, especially when the N is opaque and unbounded.

What they should do is co-sign the PRs/commits so it's the worker's personal account + the GitStart account. Then the workers are actually building a git repertoire for themselves which puts them a step closer to independence. That might go too much against the exploiting cheap labor theme that seems to be lurking in the dark here though. That said, I would love to be pleasantly surprised if GitStart is OK with co-signing commits alongside accounts directly in the control of their workers. Would definitely be based, doubt it will happen.

On top of that, we are thinking about developer profile you can share as a part of your resume. I'd love to hear some suggestions on what you think we should include in it.

In general my advice is this is one of those gray area markets where it is extremely easy to exploit workers, so you should do everything humanly possible to make sure that:

a) workers in this program are progressing with the goal being they can eventually "graduate" to the point where a middle-man is not required. This won't be possible across the board but an evil version of this startup would be designed to keep workers in this situation as long as possible, so just don't be that.

b) Allow customers who want to direct hire specific workers to do so seamlessly and don't do hefty referral fees that are enough to stop a lean startup from being able to pull the trigger. I've personally witnessed startups unable to pull the trigger in such situations because they can't afford to "buy the person out" of whatever referral company owns them. Don't be like that. If you absolutely must do a referral fee, structure it so they at least get back the money in credits with your program or something.

c) Treat workers like the assets they are -- each worker that eventually gets a job through your program becomes a marketing asset that will drive referrals from their home country when they eventually find success and tell their friends how they succeeded. Make sure you have created a positive enough experience for them that they will actually recommend you and dear god give them referral fees when they send you someone.

That's my free advice

a) we already have a sizeable alumni who have gone through GitStart over time, with many still in touch. We are in works to bring them all together in discord

b) there is no current restriction or even referral feel for both devs and companies to work with each other. The only thing we ask is for devs to either be full time on the platform or work with them directly and pause GitStart

c) good people recommend more good people! And we have a program where as alumni they get free credits for their own companies (over 5 have launched their company and used those free credits)

We currently do not have a referral program for alumni to recommend devs (it is there for currently active devs) but that’s a great idea to roll out!

At a lot of jobs I've dealt with using contractors, there was an internal concern that people external "didn't care" enough. How do you plan on addressing this concern?

It's a system that will depend a lot on trust, and it may be difficult to build that with companies whos DNA does not lend them to trust outsiders AT ALL let alone let them come in and muck with production level code (letting juniors do it!)

I'm playing devils advocate, like I said I think your idea is cool and worth exploring. Not enough companies invest in juniors to grow them into their full potential, and I commend you for this effort. Good luck.

That’s correct. Either you are a full time employee, or you get second-class culture even if you are part of internal slack. It’s very hard to get external contractors to be excited when they dont get the swag / on-sites and share the culture.

Which is why we want to have devs belong first class citizens in the GitStart Community, and join all hands / game nights and learn from others. And our integrations push through PRs and all the updates to engineering teams.

It’s not the lack of swag or on-sites. Companies usually outsource to cut costs, so there’s your problem. Also, I’m not convinced there’s correlation between being “excited” about a company and producing good quality results.

I was previously referring to the 'external "didn't care" enough' which is generally true, and IMO not an inherently bad thing on its own

But I am not sure outsourcing to cut costs is happening as much now than a few years ago. The entire outsourcing tech market is shrinking, as most teams prefer to keep devs in-house than to outsource it away.

While GitStart pays their developers, that alone could encourage better habits, I fear it could also enable this chasing reward mentality harder, setting the juniors up for failure, as well as frustrating the customer with having to deny and review multiple low-quailty PRs.

How is this avoided? This seems heavily at risk to cause more headache than help.

To prevent “Hacktoberfest” style PRs, we have a strong peer review system internally along with QA. Which is the reason why most of the above open source projects have found it a lot easier to merge GitStart PRs than the PRs by juniors posted directly

I do wonder though how we this problem can be solved for all junior devs contributing to OSS

From my experience hiring, both full-time employees and contractors can not care; it felt more about the individual's character than their employment status.

Also some cultures also show far less care than others (despite feeling the same way)

A lot of my Asian friends do not pro-actively jump into slack to not look stupid, but the moment you get on a pairing call with them the perception changes quickly as they are not as shy in a smaller group.

1) Code quality is good, I would compare it to a very good junior engineer (I suspect some senior engineers are reviewing the code before shipping it!). We are reviewing all PRs and it usually takes 1 or 2 round of feedbacks before merge.

2) Gitstart developers are very reactive on pull-requests, their response time is not a bottleneck

3) You will need to be very accurate about your features. I think Gitstart direclty makes sense for open-source projects as this is part of the culture to discuss everything on issues, to share resources (figmas, specs, technical vision). If your company already has a culture of documenting most of the knowledge async, this should be a good fit.

You are spot on that GitStart works really well for teams that have a culture or a strong intention of doing that

https://laneless.substack.com/p/the-copenhagen-interpretatio...

Again, how is the state of it not happening better than the state of it happening inequitably?

> There seems to be this in-built value in modern society that it's okay to totally screw somebody if you fit into some business-accepted guard-rails.

Again, why would you call it 'screwing' someone to offer an opportunity they can decline, that is a net improvement but not the greatest thing you could possibly offer? Per the first section of that article, what kind of sense does it make to assign blame for someone's negative situation to the first person to try to help them?

Who are these judgments actually helping, and how?

It drives down the value of the work. Short term it may be better for the person who needs the money but what would actually be better is if that person was compensated fairly.

the developers are typically folks who wouldn’t be able to get a remote job otherwise due to universities not being globally recognized or english is not super fluent. many developers grow a lot during their time at gitstart and eventually move on to getting jobs at places like Google, Amazon too. they support any developer to grow (there’s a team dedicated to figure out growth paths for each developer on the platform)

disclaimer: i used to work at gitstart

Now consider that most US developers are under-paid

When seeing $10/credit, I thought a PR this small would be just one or two credits. I'd totally pay $150 to fix 10-15 such small bugs, but only one? Am I missing something?

In this particular case there was technical discovery on a non-trivial approach to patch an npm package (which didn't work out)

But above aside, one can get a lot more milage out of GitStart if small fixes are bundled together. As that means all of them share the cost of QA (across devices), bundled code review and less context switch overhead.

The whole product disenfranchises upcoming junior devs of their potential earnings and credit for their efforts. "I built and shipped product X which generated Y revenue for company Z" read better than "I worked on a series of PRs across many different products with little insight to the product as a whole or much say in the technical direction".

This sort of thing will likely reduce number of devs that move on from junior to senior long term and put people off of joining the industry overall.

I'm glad you wrote your last paragraph! I did wonder how much of the credits cost was just overhead as the costs of small/medium/large are fairly close to each other. It makes sense to me.

We are very tempted to re-build that experience on the dashboard(at-least for our PRs), but I hope someone can launch a simple dashboard a better UX to replace the current PR detail view

You can see that this PR took a while to get merged (~2 months) with multiple iterations as shown here https://reviews.gitsense.com/insights/github?bq=8218%2Bpull-...

Full Disclosure: This is my tool

When your employer onboards new hires, do they have a commit merged into main in their first 90 minutes with the company?

Software development is an expensive business, and some companies are used to paying this much and more. The no-fix-no-fee pricing model would also command a premium over hourly work.

If you look on sites like Upwork, even developers from poor countries often cost $30+ per hour.

* "Do work, but get paid only if we use it" feels potentially exploitative. You do mention a "base pay" rate but I wonder how it compares to the "merged PR" rate?

* Code quality and adherence to internal code standards is challenging for external contributions. Open source projects, of course, are already used to this, so it's not surprising to see that's where the bulk of your current customer base lives; it's more difficult to see how this would work with other types of organization -- I'd be concerned that I'm spending more time in code review and such than I'd gain in contributed lines of code.

* The whole setup seems to fit in an uncomfortable middle ground between just hiring an offshore developer directly or through a traditional outsourcing firm, on the one hand; and hourly piecework on the other. The only advantage I see to this sort of arrangement on the hiring end compared to regular old long-contract outsourcing is that I don't have to pay for work I don't end up using, but that circles me right back to the "exploitative" part.

90% of compensation for devs is base and does not depend on the “merge PR” rate (which is in-fact 95%)

> * Code quality and adherence to internal code standards is challenging for external contributions

> The whole setup seems to fit in an uncomfortable middle ground

Majority of our customers are in-fact private and not OSS. We can unfortunately only share the latter. But it is targeted towards engineering teams that have already started to invest into DevEx and building tooling to make contribution easier We do help to set that up if customers sign up on the Team or Enterprise plan as a first sprint to add all these guardrails in place.

I agree that junior devs today are heavily exploited by existing freelance and outsourcing platforms where it's a race to the cheapest contractor in the market. For teams who want to freelance, we are not a good fit (and most likely more expensive). Where we do shine is an in-house team that does not have the bandwidth to hand-hold each external contractor one by one to become productive. And with that focus, our devs get to enjoy a fixed base stipend, career ladder internally to grow and successfully joining our customers and / or larger corps like Meta, Google and so on

(Note: I was not asked to post this)

- This does not work beyond OSS projects. This is literally a compliance leaders nightmare. I just don't know who is touching the code, how and where ahead of time, no background checks etc.

- Secondly, this feels like a nice way to "growth hack" you Github stars and fake some metrics for VCs. Your pitchdeck can 100s of contributors and 1000s of stars without really creating much value.

Because of that, 90% of users of our commercial usage today is still close-source, and biggest customer base are from heavily regulated industries like insurance, finance, and even commercial banking, with 2 of them having > $15B each under management.

Now, as you pointed out, we had to implement and background checks, audit logs and have direct full-time relationship with devs through our subsidiaries.

But what made the biggest difference was our security tooling like GitSlice, which along with dev environments cuts down majority of risk exposure.

I would be really curious why you think something like this wont work for private repos?

- They might be running shadow IT

- Security and compliance is not their priority.

Since you have implemented BG and other controls. My follow up question is are these devs in that case EOR or contractors whose payroll is processed via you. Your org starts to look like deel, remote or midsource.

The whole PR assigning to junior devs feels gimmicky, no?

However, there are two problem statements you are solving. I agree with the first premise, remote junior devs will get better opportunities and confidence when they do this exercise. I think the second part of value generation, I think risk is too high for a closed source org.

IMO if we fail as a company, it will be far more likely because of inability to deliver high quality PRs instead of inability to get through compliance.

I agree that this works for well scoped tickets that only depend on the code and testable on a staging environment. Anything outside of that needs in-house devs (or contractors) to get done.

But I also feel there is a little bit of a pandora’s box here.

The model you’re creating here is more structured ‘gig economy’ path for software dev. Sure, you’ve got things like UpWork, and other freelance products, but the purchasers (e.g., business) are effectively taking a risky bet on the work which can tamper commitment to purchasing work that way.

But with ‘no merge, no fee’ could create a very strange dynamic where companies will opportunistically throw work over the wall and create bounty-like dynamics. I don’t know if this is particularly bad for the purchaser, but for the seller that could lead to some challenges overtime (race to the bottom etc)

If it is abused we would take action to intervene but hasn’t happened yet. When it does happen (< 5%), it’s really good learning feedback for devs

But would you reckon there is another way to solve the power imbalance problem?

On this page. The error is coming from your GraphQL backend:

{ "errors": [ { "message": "has invalid format", "path": [ "createDeveloperProfile" ] } ], "data": { "createDeveloperProfile": null } }

Thanks for the report. Turns out it was one of the Falsehoods Programmers Believe About Names[0] we'll deploy the fix in a moment.

[0] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Worth acknowledging that GitStart has, at least in the past, submitted PRs to open source projects unsolicited in an attempt to bolster their reputation.

We found their PRs to be of extremely rough quality - exactly what you would expect from junior offshore developers - and it took up a non-trivial amount of our time to deal with the contributions and get them into a state where they could be merged. We would also often find 10+ email addresses associated with a single one-line change commit, which I found quite odd.

While I/we encourage contributions from developers of all levels, it felt super iffy that we were investing in coaching the junior developers of the YC/VC-backed startup, only for them to use us for cred.

In the end I believe we blocked GitStart from our repo.

I remember your case personally and reached out to you over email to apologize at that time last year. If there is anything else did wrong, please let us know

To be charitable: could have been that the commit started off big and complex, getting modified and reviewed by several people over time... before one person finally figured out how to simplify it down to one line — and so then they rebase-squashed it down to just that line, rather than polluting your commit history with all the intervening nonsense.

It is sad that developers from global south usually have to perform at a much higher level than their peers at the north, just because unfounded prejudices.

I’ve seen great developers from basically everywhere, but the vast majority is garbage (at least at first).

We have been able to eliminate a lot of un-usable PRs by having a very strong internal peer review and QA process. So PRs almost certainly works, and code review goes through at-least 2 separate reviewers

TBH, I think adding teachers that grow devs entirely through reviews is a great idea. We currently do give internal training and guidelines for reviewing PRs, but havnt gone that far yet.

Is GitStart a significant pivot from what you started with?

The harder part was getting the system to work (aka ship solid PRs while delivering a good growth path for juniors).

Most of the time was spent building a ton of in-house tech (especially around security, dev environments, review environments and so on)

We are now in a better position to automatically onboarding engineering teams (and later this year do the same for devs to sign up and start to ship PRs on the platform)

I wonder if companies will double down on full remote or this will revert back slightly.

88 PRs created: https://reviews.gitsense.com/insights/github?p=days-open&q=a...

70 merged: https://reviews.gitsense.com/insights/github?p=days-open&q=a...

7 rejected: (closed/not merged) https://reviews.gitsense.com/insights/github?p=days-open&q=a...

Interesting take away is, the merge rate is quite high, but since we can assume these PRs were created for a reason, can we also say 7 not being merged is also bad?

Full Disclosure: This is my tool

I think basic NLP on the PR decision may be able to automatically differentiate them

https://reviews.gitsense.com/insights/github?p=days-open&q=a...

In general, jr devs are net-negative. (If they're not, they're not junior! promote them!). They are an investment, they are learning and growing. It will take a senior longer to review, mentor, and coach them to a PR that the senior could've gone straight to that same PR. The whole point is that eventually you've grown another senior dev who will return big multiples on their compensation.

This sounds like you're just going to be spending sr dev time reviewing and rejecting, to have de minimis backlog items (there's a reason they're in the backlog and not prioritized) fixed, and you're not even growing a senior dev, which is the whole point.

Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle.

With GitStart, we take everything else away entirely (dev envs, preview links, mentorship, trainings etc), with strong processes to make sure PRs are heavily reviewed internally with solid QA before its pushed upstream. I think this drastically reduces cost of working with juniors to the point that its “profitable”

Right now it’s not for everyone, especially for companies where there not enough motivation internally to craft good tickets or having enough backlog thats critical enough to make use of GitStart.

Now everything aside, we actually have seen cases where devs internally grow within, apply to our customers and become full time hires! We dont bind our devs at all to join our customers directly and instead celebrate it when it happens!

"Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle."

I'm curious as to how you make this work when I'd imagine even a simple ticket for anywhere I've worked would go something like this: "first learn our monorepo, then learn how all the internal testing tooling works, and oops your PR is going to touch our in-house/NIH'd migration system. Also you can't just rename this db column, let me explain our db replication strategy (which you can't touch or observe since no way would a non-employee have any of our AWS access, even for dev). oh and Jim (haha good ole jim, he wrote like 40% of the code and then got fired after 2 years because he told the CTO to go fuck himself) wrote that code in a rush in the before times so it's creaky, try not to ever touch or look at it, so work around it in the app code even if you might otherwise want to change it" and so on and so on.

(I also find learning all this stuff - the NIH systems, the stack, who the Jim is this time around and what code he wrote, etc - is like 85% of the part of spinning up at a new company and it takes like 6 months of fireside campfire stories to pick up enough of the lore)

It sounds like a shop like this would basically mean devs are eternally in that "doesn't know about Jim's code yet" stage.

You are right, it will never replace good old Jim (or a backend dev). What it can do instead is to accelerate the devs. What if Jim created tickets to add a GitHub action to run linting on every PR, update and refactor existing code based on a new formatting rule, add more unit test cases? Basically utilize GitStart as a way to accelerate on tickets that may not be worth his time, but accelerate everyone else.

On a go to market comment, we are laser focused first to target frontend teams, particularly where as long as you have API docs (Swagger, GraphQL), and a staging environment (or we help create one) devs can go a long way without shared context.

Jim said we will add more bugs fixing it so we believe him.

> One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This enables our devs to contribute with limited codebase access.

Is this an internal tool or something you also make (or plan to make) available? We have this problem too at Ritza (a technical writing agency), where often our customers have a mono-repo with a docs/ subfolder that we need access too. Currently we solve this with some custom bash scripts and cron to sync just a subfolder to an internal copy, but is far from perfect and still involves some manual cherry-picking.

We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on.

We are considering launching GitSlice as product on its own. If you are interested, email me and I can keep you updated when its ready to test (hamza [at] gitstart [dot] com)

Yeah, I don’t care.

I don’t mean to be harsh, but if I have to justify spending my company’s money on this, this is definitely not something I’m going to say. This isn’t charity, and I’m looking for quality code.

Which is why we actively monitor review cycles as our biggest metric internally to make sure quality is solid across all active repos.

Thats why on our landing page, the focus is on the service itself with some mission interleaved. Would you reckon it's the right balance?

You gotta look at this from your customers’ perspective. All they care about is that using your service means quality work for less cost. The more you talk about other things, the more they’re going to question the quality of the work they get in return. So even though it’s a noble goal, I wouldn’t mention it at all to customers.

Where I would emphasize it is where you onboard devs to your platform, since they care about their own personal grown. Or when you hire people for your company, since people like working for a good cause. Or maybe if you’re trying to score some grant. Perhaps even some investors care, depends on the person.

But customers? Nah. They have other problems to worry about.

The reason we have not done that is because we get all devs to commit full time on the platform, and thats a deal breaker for senior devs. Part time doesnt work well for juniors to reasonable grow on the platform, but I can defn see that working for seniors.

Curiously, how you do see your normal day look like if you could something like GitStart on the side as a part time senior?

Also, I go through periods where I only want to work 8-16 hours a week, but even most contract work I find is full time.

So really for me this would allow for more liquidity in my contract work.

I would probably not do it for the money (cant imagine it would pay 150USD/h), but mostly to keep exposure to new codebases, ideas, challenges.

I think you should target this offering at people that already do contracting at first, though I think I would miss the opportunity to talk with the team. It is hard to make big changes (expected of senior folks) without design meetings and coordination.

I came across them on HN about 2 weeks ago [1] and they serve the needs of COSS (commercial open source software) projects but they seem to be bootstrapped unlike GitStart.

1: https://news.ycombinator.com/item?id=36834686

In the last month, we have rejected quite a few tickets that may have been easily tackled by a senior dev. Including technical documentation for infra, K8S, CLI agents to collect runtime traces, fixing flaky E2E tests and so on.

Hola at me if you are interested! (email in bio)

They had their Show HN about 4 months ago: Show HN: Algora – Paid open-source contributions https://news.ycombinator.com/item?id=35412226

From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.

A few ideas to solve that problem.

1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.

2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.

Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).

And also agree about engineering teams being super nitpicky. We recently rolled out a change to suggest tickets to add linting / formatting tools automatically based on nitpick comments https://gitstart.com/changelog/ticket-suggestions-private-be...

However, I am very curious about the approach of pushing out process with every PR. Would that come as form of a PR description?

Yes. Always the same though (maybe with some variants you write over time). I think the best might be to guide the receiving party so they act exactly like you want.

Example:

"Hello nice to meet you. We are a bunch of junior devs learning to make production code. We'd appreciate if you'd read our PR. However, if at first glance it doesnt look at all like something you'd merge, please simply send us a "nope" and we'll figure out why ourselves with the help of our mentors. Our goal is for you not to spend time on totally off-road PRs.

However if the PR is interesting to you, please proceed like you always do.

You can always reach us via [some form url that's automatically generated for that PR]"

Something like that that someone who can write and think has writen.

Take control at every step to prevent the receiving party to roam freely with the PR so to speak (unless it's decently good), because they might gonna go left and right - and south otherwise. They'll attack you on superficial thing. Make them a smooth funnel so they dont have to talk to nobody to move forward.

That's what came to mind.

P.s. or send them a url they follow entirely.

1. Read the PR in 15 min and come back here

2. How do you like it at first glance? A) very much, it's merged already, B) it's okay but I have feedbacks, C) not at all what we need sorry.

Etc.

And build an experience that guides them through the PR instead of getting distracted by nit picks. I we can only go so much with GitHub UX (bar chrome extension), so we may just have to rebuild the entire thing in our dashboard.

Currently we include a loom video on every PR (if its a frontend PR) along with a unique link to our dashboard to review / approve credit budgets. But we should double down to give a potentially better PR review experience and take over the experience in the long term

Another idea, maybe your PR is just a hook with no code initially, and then once the process is done via your UI, the final PR is shipped out - or the initial PR is patched.

We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action

Absolutely, this is an entire experience to rethink. If they love the experience, boom, the way I see it, you made it. Because when you think about it, you are changing things (very) deeply. Everyone ever wanted the backlog to be outsourced. I used to say, "if only we had fucking debugguers" ; to take on those nasty bugs that are essentially just a nuisance for the bottom line of business.

However it's gota be a procress for it to work. Brogrammers are just gonna mess the thing up.

I was thinking, maybe have a link in the PR for a receiving programmer to take on the PR, and then, use emails to get the programmer in the dashboard at key moments (brainstorming here, can only guess the details of how your thing work). With a dashbard for management (probably you have that already).

Think Jira, agile, process, industrialization, linkedin skill, etc. Cause the way I see it, you cant do it if you dont do it with deep integration. Otherwise human will freak out a thousand ways. Maybe have 3 different PRs for one task, the engineer can quickly browse. I know it sounds crazy but you know how this works: work from the customer and backward. Wouldnt you love to have 3 PRs you can browse and say: combine this and that and this and we good. Just throwing ideas out.

Really love that startup your working on. It goes beyond what the eye can see. Companies are bad at managing software development, they always were. They dont understand they need engineers - and technicians. They cant tell the difference, they only see programmers. With your stuff, one can imagine a future where they understand that (theyd hire engineers internally, and have technicians outsourced). I dont know. Im dreaming and halucinating at the same time, but seems to me it goes in the right direction.

If I receive one PR and its not good then my dopamine system is gonna say: it's a fail. GitStart you failed me and now Im gonna have to tell my sociopatic boss that the PR was no good for such and such and such reasons. Awful experience.

If I get 3 PRs, chances are, one is gonna be good and then they never was a single fail. Or if none is good but a combination of them could be, again, way way less of a fail for the dopamine system. "GitStart, it rocks".

I think the key idea is definitely to ship a PR with no code. You redefine the whole freaking house.

We could infant send all the draft PRs upstream. And as a senior dev upstream, you review and merge the approach that works best

It would be offensive for most in-house teams to try to give our duplicated work, but universities and bootcamps get students to learn by doing the same thing in parallel anyways

May I be brutally honest with you? I mean this to try of being of some help (how many times I wished people would just tell me what they trully think, I cant count).

I think you are trying to do two things here.

Most developers are mediocre and always will be. They just cant be autonomous like that. Growing and nurturing talented junior devs is a whole problem in itself. It's chaotic. You could but then sell him to the client once you have one that working good with a client. And again, you wont be clearing a backlog, you are recruiting and nurturing a junior dev for a client.

On the other side, there is the clearing the backlog problem for which you can use mediocre programmers. They dont need to be juniors. They just need to be able to clear a task decently well once in a while. This however can scale big. Think about how coding is trending toward AI-generated code. Most of the menial tasks and bugs and unit tests could be done by less than good programmers as long as you have the UX/UI to paliate the fact they arent autonomous. And of course some of them would learn the craft doing just that, get plenty of stars on your platform and then get properly hired for 100k a year.

I clearly dont have your experience on the subject, Im just sharing my 2cs based on my experience. My instinct would tell me to focus on the client need to clear the backlog, without adding more human management. But only you know what it's worth.

But at the end of the day, success for both devs and engineering teams (aka clients) on our platform depend on the PRs shipped. Which is why we focus all of our energy on the PR lifecycle. All key metrics driven from PRs (review cycles, time to merge, merge rate and so on).

By keeping laser focus to complete a PR, both parties win. Which is why we optimize for that first, and on top of that build further ways for junior devs to grow and teams to accelerate their velocity.

So if we need to add more human management to ship better PRs we do that. But later if solving a client need can enable them to write better tickets (which will facilitate better PRs) then we shift our focus to that.

This sounds odd. Why just from "remote countries"?

Is it because they can be paid less than in not so remote countries?

Are you going to ensure that if someone from the UK hires such a service, the worker performing it will be paid at least the UK minimum wage for the time spent?

I have a feeling this is just another way to get cheap labour.

You make it sound like it’s a Bad Thing (TM). The apprentices that sign up for this gain real world experience that’s hard to come by locally and get paid for it.

This kind of extended apprenticeship is valuable as they can go on to land remote jobs that pay them better than their local market.

Perhaps they could have worded that more clearly as: “we recruit devs . . . from low-income countries with English as their official language”

This is how they are able to make the economics work.

EDIT:

https://www.pullrequest.com/ is a comparable service (where you involve “outsiders” with your codebase) except they use senior devs rather than junior devs. Of course senior devs are more farther along in their careers so it is clear you are paying for their experience.

Stretching this to the limit, it would be a "good thing" for me if there was a law saying that I specifically should be paid more than all others of equal skill, but (even if I could somehow lobby to legislate that) I think I would prefer to compete on my own merits rather than artificial limitations.

Particularly after the publication of The World is Flat [1].

1: https://en.wikipedia.org/wiki/The_World_Is_Flat

It has a great potential for widening the social divide. Here in the UK it is illegal to hire an apprentice without at least paying them a minimum wage. The reason is that before the change, the apprenticeships were snapped up by people from wealthy background who could afford to work for "experience" or "exposure". This created a bubble, where at certain jobs you wouldn't see anyone from disadvantaged background working there, because those people had to take on jobs that weren't aligned with their interests, simply because they were poor and couldn't afford an apprenticeship. Now, the minimum wage thing is still not ideal, because in certain areas that's not enough, especially where you have a large family to support, but it is better than nothing.

A UK based, official Google Cloud partner was offering him £2.50 per hour gross for a DevOps position. Yes, £2.50.

I didn't believe it until he forwarded me their official offer letter.

I'm from a rather poor country, and when I was starting in my career I would absolutely love to earn $10/hour. In fact that would be a dream salary for me. $2.5 is not great, but it's about what I earned in my first job (and my country may not be rich, but it's still way richer than Ghana).

So I'm not sure what's wrong with that. Can our friend earn more locally? Great, they should reject the offer.

I have been working with overseas dev teams for the past 3 years, particularly in China.

If you are interested in getting developers based in China, you can reach out to me and we can have a chat.

We already have customers and a subsidiary based out of Hong Kong, and it will not be a stretch to scale those customers further from devs within China.

- HQ in China (Singapore office where I work, as a subsidiary), the contractors sign contract with a contracting firm and the contracting firm sign the contract with HQ (This is called 人力外包 "manpower outsourcing")

- HQ in China, HQ set up subsidiary in China for managing contractors, the contractors sign contract with subsidiary directly and are de facto employees of HQ except there is no official contract between them (This is called 内部/子公司外包 "internal/subsidiary outsourcing")

- HQ in Singapore, set up subsidiary in China (need to have someone with Chinese citizenship to make it smooth), contractors sign contract with Chinese subsidiary.

- Freelance arrangement where the contractor sign a freelance arrangement with company directly. The jurisdiction and validity of the contract may be quite blur so it relies on good working relationship and trust.

In my opinion, there is a large pool of talented developers based in China and the main obstacles for them to get a remote job are international bank account, language barrier and the great firewall.

If you can overcome the 3 issues then you have access to some really good developers across all levels.

And there's no way to edit the "cover letter" and they don't even ask for resume.

A simple "You are on the waiting list!" page is shown.

Unfortunately the developer waiting list is quite long so it may be a while before we get back to you. But we are scaling quickly to fix that later this year.

I love working with earlier career engineers but their code isn't known to always be very high quality. How does that work on GitStart?

We are not fully there yet, but you can see from the Open Source PRs above that its good enough that this can make an in-house team more productive than the default.

Biggest part that makes it work are enabling multiple devs to review each other, solid QA and dev environments to reduce hand-holding and a community to grow and learn from.

Larger corps like Google already have this infra setup, but most teams cant afford to build it internally.

It got merged so clearly the devs find value in the work but I wouldn't call that production ready.

We first got the more experienced junior on the repo review others. Later on, we started to enable multiple devs to work on the same PR initially, review each other and best one sent back

And with GitSlice, we have been able to take very large codebases and slice it to a smaller repo that is much easier for juniors to work on.

So now we get teachers and seniors to train juniors, but they are not in the loop of the PR execution anymore.

For example, in my first job, I was tasked with greying out a button after it had been clicked. Trivial and generic task. But I was paired with a brand new senior to do the work and we spent a day trying to find the correct button (being new and wanting to seem useful, we didn't want to ask).

It got a lot better with covid which started the wave of remote work and teams started to care about writing tickets for the first time.

Currently we solve it with ticket templates, but we are now doubling down on using AI to help craft and improve ticketing writing. It’s still under private beta, but will be live for everyone soon https://gitstart.com/changelog/tickets-by-chat

> Neo led the round alongside Microsoft CTO Kevin Scott, Google VP Parisa Tabriz, Andela founder Iyinola Aboyeji, Uber CEO Dara Khosrowshahi, Instagram VP Maria Zhang, Circle CTO Li Fan and VP Yongsheng Wu, Robinhood VP Surabhi Gupta, Quora CEO Adam D’Angelo, GitHub technical advisor Omoju Miller, Gigster founder Debo Olaosebikan, BloomTech founder Austen Allred, Replit CEO Amjad Masad, Airbnb co-founder Nate Blecharczyk, Mike Schroepfer and others.

I wouldn't exactly call this list unremarkable

I think the quality of the PRs was fine, I cannot say much about the business model / pricing since we got them for free (out of nowhere - they just started making PRs - much appreciated!)

There is nothing stopping devs from getting recruited directly, in-fact we want that to happen! Its a major success story for us when devs get hired, ideally back to our customers :)

As a result, the end team that uses GitStart has full ownership of all code that gets merged.

However you can assign future bug fixes and maintenance work back to GitStart.

i would think gitstart as an extension to engineers themselves instead of working in silo

disclaimer: i used to work at gitstart

I suppose that the need for this comes out of the fact that.. we've written a ton of code that needs to be maintained at this point. It's not interesting work, but it's busy work that's still important.

BTW, I could write code, so your page "You're on the waiting list!" will show approximate time.

I could understand, if you don't want to show number of people in wait list, but simple algorithm could forecast and show approx days to wait.

Thank you!

We have automated on-boarding flow only for JS / TS, but we in-fact support 15 tech stacks including React Native, .Net, Native Mobile & Django

Mobile is our largest tech stack after JS / TS because we were able to build review environment for mobile apps that make it drastically easier for junior devs to review and QA their PR before its pushed upstream without having the actual native device.

I can see image on the left, but the form on the right is offscreen and I think you disabled scrolling so there is no way to get to it.

I had to look at this page on the desktop to learn about that form.

For now, it's best to sign up from a desktop, as the onboarding flow requires connecting GitHub and specifying repos, so this is not very convenient from mobile right now.

technical architecture, API design, breaking down large projects, infrastructure and so on.

All of the above require senior in-house talent. So we want to become the best place for juniors to grow and enable them to join companies to lead the above initiatives.

I do not see a way where we will reduce the need for senior positions.

I am really skeptical about a service (like pullrequest.com) where external reviewers come in to gate-keep internal PRs. It can work like CI / CD checks (e.g pentesting, SonarCube). But its next to impossible to truly suggest changes that make a difference without knowing the context.

At GitStart, we have tried hard to make sure we are accelerate and empower the in-house teams, instead of shrinking them or trying to replace their need.

eventually you will have devs gaming the system by working on multiple tasks from multiple outsourcers (like multi-apping for food delivery)

then the quality of the work declines. rejection rate increases. then the base salary will have to go down or become entirely task based.

Essentially it allows us to give standardise pricing for similar PRs regardless of time spent on them.

Would it be more useful if we launch a calculator where you can input those variables and get back a credit estimate?