-2

Some work is conducted by many people, in many pieces, but when that work is submitted, all that work is repackaged and the authorship of those works is changed to be person submitting the work, not the author. This authorship is only relevant within the company. [1]

There are technical solutions in place to ensure correct authorship is retained, but that is not used. Is this not unethical in taking away the credit from the author. Is there any professional ethics I can point out to people in team not to do this?

I have seen this many instances in the corporate world people just do this and gain credits without much efforts but the person who has contributed to the work is never getting any credit.

This is big bane in the the corporate world or companies... Please let us know being leads how can we overcome this and making aware of this ethics to fellow members.

If it matters for your answer, the context around this is software development.

[1] The work are git commits. When the work is submitted to repo the commits are squashed before pushing.

9
  • 4
    I’m voting to close this question because this is a technical question not one related to workplace relationships. Sep 8 at 1:06
  • 3
    I suggest the new question title “Freaking about Forking”
    – mxyzplk
    Sep 8 at 1:06
  • 3
    This is not a technical question, though the question could be made to better stand out. "Is there any Professional ethics I can point out to people in team not Todo this?" Sep 8 at 2:43
  • 1
    I don’t agree with the rewrite, it accepts the premise that a squashed/truncated commit history is the same as “changing authorship”.
    – mxyzplk
    Sep 8 at 4:39
  • 1
    Where are you in the World? India will have its own attitude / response for example.
    – Solar Mike
    Sep 8 at 5:52
5

I don't see many problems here.

Authorship is often a term used in copyright law to refer to protections provided to the creator of a work. It doesn't really apply to what you do at work, since in most cases the company owns the work. You don't have any say in how the product is sold or licensed. The Law Stack Exchange may be a good place to explore your legal relationship to your employer and copyright law.

Squashing commits in git is a common practice to keep the history of a shared code branch clean and easy to follow. A single developer may make many commits when developing a feature, but only a single commit into an integration branch is required to make it easier to cherry-pick the changes into other branches or revert the changes. There are plenty of good reasons to squash commits, and the act of squashing is not unethical by itself.

It would be unprofessional and unethical for someone to attempt to hide, distort, or misrepresent the work of their colleagues. However, code commits are also not a good way to measure contributions. There are plenty of ways to contribute as a software developer that aren't code commits - design, pair programming, code reviews, manual testing are just a few examples of work that doesn't get associated with git commits.

It seems like the perceived problem is that employees aren't recognized for their work because their name doesn't appear in the commit history of a code repository. If the organization is actually using that as a metric for employee performance, that would be a broader organizational issue. What I don't see is any evidence that this is happening, though.

If you believe that your contributions to the team, the project, and the product are not being seen, that's a conversation to have with your manager. However, just because your name isn't associated with specific code changes doesn't mean that the team doesn't see your contributions.

If you are in an organization that values code commits and having your name in the source code repository history, I'd consider that a poor working environment, especially given the technical practices. There's a big disconnect between the team choosing to use a perfectly fine technical practice and how the organization measures team success. It could range from malicious intent, abusing the technical practices to earn better performance reviews, to not understanding the implications of the technical practices on others. The underlying problem, however, is how the organization measures performance.

6
  • 3
    I disagree that performance reviews are the only (or even the main) reason why this matters. Without an accurate git history, it is difficult to determine who made a particular change, and so why. git blame exists for a reason, finding the right person quickly is valuable when there's an issue. Sep 8 at 9:51
  • @JoeStevens I don't agree. I can count the number of times I've used git blame on one hand. In my experience, it's not helpful since the change was made years ago and people have forgotten or the person who made the change left the company. Things like pair or mob programming also break git blame, especially if the keyboard is being passed around - the person's credentials are associated with the computer, not the typing. Sep 8 at 10:59
  • 1
    Regarding git blame, the mentality is really around trying to identify the change, not the person. It doesn't matter if 1 person or 100 people worked on a change, provided it's sufficiently small and it's easy to understand. In complex code bases, git blame is an amazingly useful tool (at least for some people). Sep 8 at 12:09
  • I'm not going to DV this answer, and I know the question is a bit unclear, but identifying that the workplace is measuring performance in a poor manner isn't that useful to the OP who wants to be recognised for their work. Sep 8 at 12:12
  • @GregoryCurrie I am unconvinced that the OP isn't being recognized for their work, which is why the next step has to be a conversation with their manager. Having their name in the version control system is not the only way, and definitely not the best way, for having work recognized. Sep 8 at 13:06
0

How to overcome this? Spread the credit around to your team. A good manager takes the blame when things go wrong and gives the credit when things go well. If you do that, your team will succeed more than other teams and people will want to work on your teams. You can't change what other managers do, but you can compete with them for top people and by sharing credit, you will.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .