5 ms·

These guys also tried to submit PRs on the Notesnook[0] repository. The PRs are really good but there's no way to talk to the actual developer working behind th

These guys also tried to submit PRs on the Notesnook[0] repository. The PRs are really good but there's no way to talk to the actual developer working behind those PRs. They have a single central account named "gitstart" and all PRs that any of their user works on falls under that account. Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization. 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 https://github.com/streetwriters/notesnook [1] https://developercertificate.org/ https://developercertificate.org/

Kiro 3y ago
What's the point of DCO? Really don't understand why you would want to cripple yourself with that.
- sam0x17 3y ago
  It's a lot easier to trust an individual than it is to trust an entire organization which is effectively trusting every individual who may have access at that org at any given time. 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.
  - macocha 3y ago
    What do you mean by co-signing? We currently do attribute the work using "Co-authored-by:" in the commit message. I'm not sure if there's any other/better way to do it. 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.
    - completeshock 3y ago
      "Co-authored-by" cannot be validated. Well, no commit can without signing (and there are issues even withthat).
      - hzia 3y ago
        How do you sign multiple devs on a commit though? Would it be a joint PGP key signed by all keys of all devs that helped with the PR?
        completeshock 3y ago
        You can't.
    - sam0x17 3y ago
      I retract my previous statement! If you're already doing the Co-authored-by, that is fantastic, then their names are clickable on GitHub, and the developers themselves will be able to directly interact through their own GitHub accounts if they are @'ed by the customer. This is great. Definitely advertise that aspect. 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
thaumasiotes 3y ago
> Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization. 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. Where does this require that the submitter not be an organization? Even if you're fully committed to that idea, the obvious approach would appear to be: (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.
- wccrawford 3y ago
  That's a weird document. It seems that it actually wants the submitter to certify that either A & B are true, or C is, and that D is acceptable. But it lists them like you must accept all 4, but all A & C can't both be true at the same time.
  - thaumasiotes 3y ago
hzia 3y ago
It is on our roadmap to properly integrate DCO on the platform, as its a hard blocker for all repos under the linux foundation. We already add each devs that touches the PR internally as co-author now 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
- deleted 3y ago
  [deleted]
abstractcontrol 3y ago
> The PRs are really good but there's no way to talk to the actual developer working behind those PRs. 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.
- hzia 3y ago
  We currently attribute commits back to every single dev involved in a PR (including reviewers) as co-authors. We also actively work with our customers to allow devs to mention their contributions in their CV publicly. And you can always reach out to them directly if they have an open position (especially mentioning your experience working with them through GitStart) What would be an ideal way to attribute the hard work back to the devs in our case?
- comprev 3y ago
  I don’t think you’re being treated any more unfairly than anyone else trying to break into the US market. It’s simply a case that a decade of experience and being a skilled programmer are not enough to stand out from the crowd. Depending on your location there may be legal restrictions preventing from US companies hiring you - even through a B2B contract.
  - hzia 3y ago
    Unless there is a strong regulation like HIPAA, I have seen setting up a US based company (through Stripe Atlas) take care of most legal woes. 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
    - completeshock 3y ago
      Most companies hiring remotely don't have if your 1-person company is US-based or not. 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.

Kiro 3y ago

What's the point of DCO? Really don't understand why you would want to cripple yourself with that.

sam0x17 3y ago
It's a lot easier to trust an individual than it is to trust an entire organization which is effectively trusting every individual who may have access at that org at any given time. 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.
- macocha 3y ago
  What do you mean by co-signing? We currently do attribute the work using "Co-authored-by:" in the commit message. I'm not sure if there's any other/better way to do it. 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.
  - completeshock 3y ago
    "Co-authored-by" cannot be validated. Well, no commit can without signing (and there are issues even withthat).
    - hzia 3y ago
      How do you sign multiple devs on a commit though? Would it be a joint PGP key signed by all keys of all devs that helped with the PR?
      - completeshock 3y ago
        You can't.
  - sam0x17 3y ago
    I retract my previous statement! If you're already doing the Co-authored-by, that is fantastic, then their names are clickable on GitHub, and the developers themselves will be able to directly interact through their own GitHub accounts if they are @'ed by the customer. This is great. Definitely advertise that aspect. 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

thaumasiotes 3y ago

> Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization. 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. Where does this require that the submitter not be an organization? Even if you're fully committed to that idea, the obvious approach would appear to be: (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.

wccrawford 3y ago
That's a weird document. It seems that it actually wants the submitter to certify that either A & B are true, or C is, and that D is acceptable. But it lists them like you must accept all 4, but all A & C can't both be true at the same time.
- thaumasiotes 3y ago

hzia 3y ago

It is on our roadmap to properly integrate DCO on the platform, as its a hard blocker for all repos under the linux foundation. We already add each devs that touches the PR internally as co-author now 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

deleted 3y ago
[deleted]

abstractcontrol 3y ago

> The PRs are really good but there's no way to talk to the actual developer working behind those PRs. 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.

hzia 3y ago
We currently attribute commits back to every single dev involved in a PR (including reviewers) as co-authors. We also actively work with our customers to allow devs to mention their contributions in their CV publicly. And you can always reach out to them directly if they have an open position (especially mentioning your experience working with them through GitStart) What would be an ideal way to attribute the hard work back to the devs in our case?
comprev 3y ago
I don’t think you’re being treated any more unfairly than anyone else trying to break into the US market. It’s simply a case that a decade of experience and being a skilled programmer are not enough to stand out from the crowd. Depending on your location there may be legal restrictions preventing from US companies hiring you - even through a B2B contract.
- hzia 3y ago
  Unless there is a strong regulation like HIPAA, I have seen setting up a US based company (through Stripe Atlas) take care of most legal woes. 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
  - completeshock 3y ago
    Most companies hiring remotely don't have if your 1-person company is US-based or not. 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.