Kratos: Concerning the authorship of Kratos files

Created on 6 Jul 2018  ·  23Comments  ·  Source: KratosMultiphysics/Kratos

Hi all,
It's been a while since we do not discuss about this topic, but it's a problem that appears repeatedly in Kratos (and in many other codes I guess).
The typical case is the following: someone modifies a file which was originally written by someone else, then, he adds his name as a co-author of the file. In some cases, the name of the original author is replaced.
When the addition of a co-authorship is done with the permission of the original coder, there is no problem. Otherwise, the situation can become uncomfortable. What if those changes were not significant enough? What is considered significant?
I think it is worth to discuss this issue, and reach some kind of agreement. It would be great if we set up some criteria.
Referencing: @KratosMultiphysics/technical-committee @KratosMultiphysics/solid-mechanics @KratosMultiphysics/fluid-dynamics @KratosMultiphysics/dem @KratosMultiphysics/structural-mechanics

Discussion Help Wanted Question

Most helpful comment

My personal opinion is that the name or names that should appear at the top of the file should be the answer to: 'Who should I ask in case of problems with this file? Who can explain why this was coded like that?'

All 23 comments

My personal opinion is that the name or names that should appear at the top of the file should be the answer to: 'Who should I ask in case of problems with this file? Who can explain why this was coded like that?'

The problem with that is in the case that person has stopped contributing to the code

Then, everyone knows that the file is abandoned, I think that the information is relevant. However, if there's someone else doing maintenance of that file, their name can appear as well.

For example I am thinking about the shells of @MassimoPetracca, right now @philbucher is the responsible of maintenance

So, what is your proposal?

It is difficult, just pointing flaws of other systems right now

Code ownership. Each subtree of the repository can have a file listing the user ids of the “owners” of that subtree . Subdirectories also inherit owners from their parent directories, although that can be optionally suppressed. The owners of each subtree control write access to that subtree, as described in the code review section below. Each subtree is required to have at least two owners, although typically there are more, especially in geographically distributed teams. It is common for the whole team to be listed in the owners file. Changes to a subtree can be made by anyone at Google, not just the owners, but must be approved by an owner. This ensures that every change is reviewed by an engineer who understands the software being modified

https://arxiv.org/pdf/1702.01715.pdf -> Google code development

I will let others write, but some simple questions should be answered in this issue:
-if I add one 'override' in one file, can I be considered co-author?
-is formatting 'a significant change'?
-is authorship important?
-etc

  • I consider myself collaborator when I have done just some minor corrections
  • Nope, I don't even consider formatting as collaboration
  • Yes, well with the BSD licence is less important because you have a lot of freedom, but in a more generic case it is important in order to avoid legal conflicts

I would say that you can be a co-author if you add some methods or
implementations to that file... formatting and style stuff should not be
enough. Just my opinion... I don't know how it works in other codes... ^^

@loumalouomega I don't think that approach apply to us (about the google organization). We have team maintainers for that.

Under my point of view one should be added as author of the file if he is actively participating in his development, or he/she is defacto the only person who is touching it. but if we want to keep it that way we have to respect also the previous owners of such file. I am thinking now for example in the code Carlos Labra and Nelson did, just to put an example because were the ones I had more contact with.

That being said, I consider that authorness can lead to misunderstanding and should be removed. To begin with, if someone wants to know the contributions on some file this information can be easily extracted from the history of such file.
Also, if we wanted to use to identify everyone ho has made a contribution, major or minor, and being kratos a code with more than +80 dev we would end with a ridicule long list at the top of every single file. I, for example, probably have touched half of Kratos code and it makes no sense that I appear as an author in 90% of those files.

If appear as an author of something as a credit is so relevant we should clearly state that in a readme in the application folder for example.

TL;DR: In me opinion we should remove authors or at most just leave authors who are relevant in that specific file.

Regarding the issue of listing authorship, I have mixed feelings. The good part of it is what you say, knowing who can explain to you why things are the way they are, how they can be improved or what was tried and didn't work out. However, in many cases you can also tell that from the file history on github. The bad part is when people take it as a mark of "ownership" and this generates friction within the group or turns into a way to plant your flag in the pieces of your little code kingdom.

@maceligueta some more cases I have found hard to answer in the past:
-If I create a new file because I am separating a header-only class into header and source, who is the author of the new file? (When I do it, I don't feel like I am the author of anything, even if sometimes it feels like a lot of work). Note that the person who wrote the original code will not even be recognized by github, because I am creating a new file from scratch.
-What if I take a function from an existing class and move it to a new utility? (Think of reducing duplication, maybe I just take one implementation and call it from several places)
-Moving things to other applications or to/from the core (again, if it is not done carefully, git might not recognize the original authors).

@loumalouomega I would not bring licensing into this, since it is different from authorship. You could be the author of something while the copyright remains on the hands of your employer, or even of the entity who is paying your PhD grant.

@roigcarlo I had already written most of my answer when I saw yours, but I tend to agree with your points.

Mentioning @KratosMultiphysics/team-maintainers in case we have missed someone.

I believe that the people appearing in the list of authors of any file should only be those who completely (or almost completely) know and understand how it is implemented and why. And I think they should be there regardless of their appearance in the history of changes of GitHub. And I am saying this because, there may be cases when 2 people work together in the implementation of 1 file and only 1 of them commits the changes of the file (just because it is impossible to commit the same thing twice ^_^')

@jcotela Sorry if I put the licensing as point, it was only a point, that in this case maybe is not important.
Regarding the refactoring of the code, I don't consider myself as author, but I consider myself as collaborator, in the sense I helped the file to reach the current state

If authorship is hard to define, I can't imagine what 'collaborator' can be extended to! Lol.

Then add co-author or other-author...

I am mainly in favor of removing the authors from headers. Actually most of my reasons has been commented before:

  • Not clear definition
  • Including all authors would be extremely long.
  • Refactoring the code will mess it up even more.
  • etc....

And to add that I don't see it so useful to try to maintain it.... I'm not trying to sub-estimating the authorship, but I think that it gives more headache than benefit.

I understand that developers like to be recognized by their codes. Nevertheless in an open source community they can be best recognized by their "usefulness" and "effectiveness" by solutions they provide. (And the effectiveness is not only restricted to coding) At least for me is more important to be recognized by my friends rather than having my name read by someone who download the code. (Which in many cases my name is only there because someone has saved my file with another name and modified it without any contribution from me)

Just to wrap up, I would be glad if all of the collaborators in Kratos put their membership as public. At least that would help us to be more visible....

I like authors being listed in the files...

We have been discussing this in @KratosMultiphysics/technical-committee

Overall the code of conduct in this sense should be based on simple rules of politeness. However let's try to formalize it a bit more:

We believe that someone who contributed a new code feature is the author of that.

Anyone modifying/correcting/improving a given feature is understood to be doing for the Kratos's good and wouldn't be considered as author unless the original author/s agree about ADDING him as a new author.
Note that "obvious refactorings" should NOT be considered as contributions.

In the case in which the original author is not any longer active then someone __doing significative modifications__ can ADD himself to the list of authors, taking over the responsability of the maintenance of the given file.

hopefully this discussion can lead to a code of conduct

Do I add this to the Wiki?

@loumalouomega Not yet, let's wait for possible contributions or replies. For this reason the Tech Comm decided not to write this officially yet.

@loumalouomega now that there are no more comments, would you please add it to the wiki?

Was this page helpful?
0 / 5 - 0 ratings