9 ms·

Good. Yeah it doesn't do much for the community, but I got scolded in the past for squeezing in commits to open source repositories that aren't work related dur

Good. Yeah it doesn't do much for the community, but I got scolded in the past for squeezing in commits to open source repositories that aren't work related during work hours. I know, I know, I shouldn't be doing that in the first place, but it still sometimes happens, and just being able to keep the profile private is easier than waiting with committing until after work hours. Not everything I do on GitHub should be broadcasted to my entire workplace

WhyNotHugo 4y ago
I've seen colleagues scrolling Facebook or similar crap during working hours. Contributing to a FLOSS project is equally work-unrelated, but seems like a better way to slack of TBH.
crossroadsguy 4y ago
> Not everything I do on GitHub should be broadcasted to my entire workplace And vice versa. That’s why I’ve to keep two separate accounts - main/personal @firstname and another @shortname-work.
- Lammy 4y ago
  While in practice they probably won't ever care, this is technically against the terms of service unless work is a Github Enterprise customer: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#b-account-terms https://docs.github.com/en/site-policy/github-terms/github-t... > One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).
  - tomsthumb 4y ago
    presumably work accounts are paid
    - eyelidlessness 4y ago
      The accounts aren’t but the orgs typically are and I think that passes muster. Ultimately they just don’t want people astroturfing or otherwise deceptively maintaining multiple accounts on behalf of paying customers.
  - ollien 4y ago
    So, take this for what it is because I'm just some random guy on HN, but my company required us to make our Github primary email our work email to receive alerts. I wasn't comfortable doing on my personal account, and was told to make a second one. We followed up with our Github rep regarding this clause, and they told us that because the account would be primarily used for Enterprise (even though it's a free account), it's not something they consider a violation of their policy. Allegedly this happens with quite a lot of their customers.
  - exikyut 4y ago
    Genuine question, I don't actually know the details: how does the contemporary notion of avatars and usernames to distinguish identity or alter-ego interact with the notion of what a legal entity is? If I practice security hygiene across multiple identities online and only do certain things using certain representations/usernames... how would it work out in practice if I tried to argue that each representation was a distinct and separate entity of agency? Hmm. Thinking about this I now realize that identity fraud would probably be a lot harder to pin down if things leaned in the direction I'm describing, so perhaps not.
  - rectang 4y ago
    The single account requirement is problematic until Github makes it possible to grant personal access tokens which don't give access to all of your repos, including across multiple organizations.
  - bbkane 4y ago
    Not a lawyer, but I interpret Ben writing code at work as a different legal entity than Ben writing code at home in regards to code ownership under CA law.
yepguy 4y ago
There is also git-privacy[1] for reducing the accuracy of all of your commit timestamps. [1]: https://github.com/EMPRI-DEVOPS/git-privacy https://github.com/EMPRI-DEVOPS/git-privacy
eek2121 4y ago
I mean, vice versa. I have to hide my private code from public eyes for the same reason.
platz 4y ago
how is that different from just creating an account not tied to your online identity?
eyelidlessness 4y ago
> I know, I know, I shouldn't be doing that in the first place You almost certainly should, and if you’re scolded for it you probably work for parasites. You’re not wrong to hide that activity from them but I hope you’ll find a role where contributing back is valued not chastised.
- hobofan 4y ago
  > repositories that aren't work related during work hours
  - eyelidlessness 4y ago
    I still don’t see the problem. Either they’re sitting around with nothing to do, and therefor the contributions are a clear positive, or they’re neglecting the work they’re supposed to be doing and the contributions are beside the point.
    - fiddlerwoaroof 4y ago
      I think this can cause legal issues: ianal, but generally work done during company time with company equipment belongs to the company, and I’d guess a litigious company could cause problems for open source projects contributed to in this fashion.
      - eyelidlessness 4y ago
        As long as the projects being contributed to are using well understood licenses, the projects themselves are fine. If the employer wants ownership of any of the work, the ownership they’ll get is rights to claim they were contributors. Still mostly good!
        someonenice 4y ago
        What about the other way - if the commit is "damaging" in nature specially on a competitors repo. For example the recent NPM commit that wiped user data. If its done on company time using company laptop, will the company be liable ?
NegativeLatency 4y ago
I’ve had jira tasks for committing to open source repositories at previous jobs. Sounds like your employer needs to reconsider or have the value be explained to them.
timwis 4y ago
You can also just change the timestamp of your commits
hapiri 4y ago
I don't know why you should be apologizing for this. Your employer has benefited from FOSS products, your PR is the payment back for the community. I hope you can voice your opinion back. It would be such a dystopia if your employer's attitude become widespread.
- uuyi 4y ago
  Got to say my employer has a shitty attitude towards this. Even if contributing fixes to components that we use as part of defects. I still do it. I have a separate non work github account and I just scp myself the diff and PR it from my personal account in the evening. Fuck 'em.
- 9dev 4y ago
  That may be true in principle, but you’re simply not getting paid for contributing to open source projects unless your employment contract says exactly that. Im not opposed to idling, brains need that. But I don’t think it’s fair to use your company time to work for something else, no matter how good the cause - I wouldn’t want my engineers to help out at a homeless shelter either, even though I’m generally in favor of that.
  - WorldMaker 4y ago
    If your company is paying you to work on Product X and Product X depends on Open Source Library Y, Open Source Library Y's bugs are Product X's bugs. Open Source Library Y's features are often productivity enhancements that make Product X better. Your company is paying you to work around Open Source Library Y's defects and use Open Source Library Y's productivity enhancements, no matter what. Sometimes the fastest way to work around Library Y's defects is to fix them yourself and sometimes the best way to get more productivity out of tools like Library Y is to contribute Library Y features yourself. Because your company may see Open Source Library Y as free as in beer they may not value the vendor relationship with Open Source Library Y. The "cultural" Maintenance Agreement with Open Source "vendors" is that good open source users contribute back to open source those bug fixes they need for workarounds and those features they request for productivity benefits. Compared to the costs of Maintenance Agreements with many large, classic closed source vendors, the cost of a few hours labor on dependencies to products is often quite cheap relatively speaking especially with the "free as in beer" platform/networking effect that other "good" companies following cultural Maintenance Agreement norms contribute as well. The only real missing ingredient is that because that Maintenance Agreement is cultural more than it is written down in a way that Corporate Lawyers can read it and Actuaries and CPAs can understand it to be an asset and/or liability that impacts the books, it just becomes invisible guilt: either the guilt that you aren't doing your part as a developer with respect to that culturally assumed Maintenance Agreement OR the guilt that you are doing your part but that your company may find out and claim you are wasting their time. But seriously, that vendor relationship even though most of the "assets" are "free as in beer" should be on the books and have its own billing codes for the culturally encouraged "liabilities" of Maintenance Agreements to spend a few hours of developer time here or there for the "greater good", but also the specific good of "making Product X better" because that is an asset directly related to the performance and success of "Product X".
serial_dev 4y ago
I'm also happy to see this feature, just a month ago I was looking for it and was disappointed I can't hide my activity. I was sick with COVID, but about one week in, I had an afternoon where I didn't feel completely sick, so I wanted to tinker with some code for an hour. I couldn't commit because I was paranoid that my boss/coworkers would freak out that I coded an hour while I was sick. Same is true if your coworkers follow you, and you start starring or contributing to repos about interview questions, whiteboard questions, etc. There is a 98% chance nobody would notice or care, but I don't want unnecessary drama because I enjoy using GitHub in my free time.

WhyNotHugo 4y ago

I've seen colleagues scrolling Facebook or similar crap during working hours. Contributing to a FLOSS project is equally work-unrelated, but seems like a better way to slack of TBH.

crossroadsguy 4y ago

> Not everything I do on GitHub should be broadcasted to my entire workplace And vice versa. That’s why I’ve to keep two separate accounts - main/personal @firstname and another @shortname-work.

Lammy 4y ago
While in practice they probably won't ever care, this is technically against the terms of service unless work is a Github Enterprise customer: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#b-account-terms https://docs.github.com/en/site-policy/github-terms/github-t... > One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).
- tomsthumb 4y ago
  presumably work accounts are paid
  - eyelidlessness 4y ago
    The accounts aren’t but the orgs typically are and I think that passes muster. Ultimately they just don’t want people astroturfing or otherwise deceptively maintaining multiple accounts on behalf of paying customers.
- ollien 4y ago
  So, take this for what it is because I'm just some random guy on HN, but my company required us to make our Github primary email our work email to receive alerts. I wasn't comfortable doing on my personal account, and was told to make a second one. We followed up with our Github rep regarding this clause, and they told us that because the account would be primarily used for Enterprise (even though it's a free account), it's not something they consider a violation of their policy. Allegedly this happens with quite a lot of their customers.
- exikyut 4y ago
  Genuine question, I don't actually know the details: how does the contemporary notion of avatars and usernames to distinguish identity or alter-ego interact with the notion of what a legal entity is? If I practice security hygiene across multiple identities online and only do certain things using certain representations/usernames... how would it work out in practice if I tried to argue that each representation was a distinct and separate entity of agency? Hmm. Thinking about this I now realize that identity fraud would probably be a lot harder to pin down if things leaned in the direction I'm describing, so perhaps not.
- rectang 4y ago
  The single account requirement is problematic until Github makes it possible to grant personal access tokens which don't give access to all of your repos, including across multiple organizations.
- bbkane 4y ago
  Not a lawyer, but I interpret Ben writing code at work as a different legal entity than Ben writing code at home in regards to code ownership under CA law.

yepguy 4y ago

There is also git-privacy[1] for reducing the accuracy of all of your commit timestamps. [1]: https://github.com/EMPRI-DEVOPS/git-privacy https://github.com/EMPRI-DEVOPS/git-privacy

eek2121 4y ago

I mean, vice versa. I have to hide my private code from public eyes for the same reason.

platz 4y ago

how is that different from just creating an account not tied to your online identity?

eyelidlessness 4y ago

> I know, I know, I shouldn't be doing that in the first place You almost certainly should, and if you’re scolded for it you probably work for parasites. You’re not wrong to hide that activity from them but I hope you’ll find a role where contributing back is valued not chastised.

hobofan 4y ago
> repositories that aren't work related during work hours
- eyelidlessness 4y ago
  I still don’t see the problem. Either they’re sitting around with nothing to do, and therefor the contributions are a clear positive, or they’re neglecting the work they’re supposed to be doing and the contributions are beside the point.
  - fiddlerwoaroof 4y ago
    I think this can cause legal issues: ianal, but generally work done during company time with company equipment belongs to the company, and I’d guess a litigious company could cause problems for open source projects contributed to in this fashion.
    - eyelidlessness 4y ago
      As long as the projects being contributed to are using well understood licenses, the projects themselves are fine. If the employer wants ownership of any of the work, the ownership they’ll get is rights to claim they were contributors. Still mostly good!
      - someonenice 4y ago
        What about the other way - if the commit is "damaging" in nature specially on a competitors repo. For example the recent NPM commit that wiped user data. If its done on company time using company laptop, will the company be liable ?

NegativeLatency 4y ago

I’ve had jira tasks for committing to open source repositories at previous jobs. Sounds like your employer needs to reconsider or have the value be explained to them.

timwis 4y ago

You can also just change the timestamp of your commits

hapiri 4y ago

I don't know why you should be apologizing for this. Your employer has benefited from FOSS products, your PR is the payment back for the community. I hope you can voice your opinion back. It would be such a dystopia if your employer's attitude become widespread.

uuyi 4y ago
Got to say my employer has a shitty attitude towards this. Even if contributing fixes to components that we use as part of defects. I still do it. I have a separate non work github account and I just scp myself the diff and PR it from my personal account in the evening. Fuck 'em.
9dev 4y ago
That may be true in principle, but you’re simply not getting paid for contributing to open source projects unless your employment contract says exactly that. Im not opposed to idling, brains need that. But I don’t think it’s fair to use your company time to work for something else, no matter how good the cause - I wouldn’t want my engineers to help out at a homeless shelter either, even though I’m generally in favor of that.
- WorldMaker 4y ago
  If your company is paying you to work on Product X and Product X depends on Open Source Library Y, Open Source Library Y's bugs are Product X's bugs. Open Source Library Y's features are often productivity enhancements that make Product X better. Your company is paying you to work around Open Source Library Y's defects and use Open Source Library Y's productivity enhancements, no matter what. Sometimes the fastest way to work around Library Y's defects is to fix them yourself and sometimes the best way to get more productivity out of tools like Library Y is to contribute Library Y features yourself. Because your company may see Open Source Library Y as free as in beer they may not value the vendor relationship with Open Source Library Y. The "cultural" Maintenance Agreement with Open Source "vendors" is that good open source users contribute back to open source those bug fixes they need for workarounds and those features they request for productivity benefits. Compared to the costs of Maintenance Agreements with many large, classic closed source vendors, the cost of a few hours labor on dependencies to products is often quite cheap relatively speaking especially with the "free as in beer" platform/networking effect that other "good" companies following cultural Maintenance Agreement norms contribute as well. The only real missing ingredient is that because that Maintenance Agreement is cultural more than it is written down in a way that Corporate Lawyers can read it and Actuaries and CPAs can understand it to be an asset and/or liability that impacts the books, it just becomes invisible guilt: either the guilt that you aren't doing your part as a developer with respect to that culturally assumed Maintenance Agreement OR the guilt that you are doing your part but that your company may find out and claim you are wasting their time. But seriously, that vendor relationship even though most of the "assets" are "free as in beer" should be on the books and have its own billing codes for the culturally encouraged "liabilities" of Maintenance Agreements to spend a few hours of developer time here or there for the "greater good", but also the specific good of "making Product X better" because that is an asset directly related to the performance and success of "Product X".

serial_dev 4y ago

I'm also happy to see this feature, just a month ago I was looking for it and was disappointed I can't hide my activity. I was sick with COVID, but about one week in, I had an afternoon where I didn't feel completely sick, so I wanted to tinker with some code for an hour. I couldn't commit because I was paranoid that my boss/coworkers would freak out that I coded an hour while I was sick. Same is true if your coworkers follow you, and you start starring or contributing to repos about interview questions, whiteboard questions, etc. There is a 98% chance nobody would notice or care, but I don't want unnecessary drama because I enjoy using GitHub in my free time.