[policy, no patch] Determine format for commit credit for individuals/organizations/customers

I am personally more in favor of using git notes. Another good resource to read: http://git-scm.com/blog/2010/08/25/notes.html

Regardless of whether these are in [a multiline] commit message or a git note, I do not think that doing the equivalent of username@company is a very sustainable approach. Not to mention we already have the standard git attribution format (in the form of an email address). I think just by using CSV we can determine when an attribution is associated with an company, client or organization. The easiest way to parse this: first one is always a user, any additional "emails" are simply nodes to the respectable entity.

The following is what I would like to propose. Keep in mind this isn't real data, it's just for formatting sake:

Initial commit:

git commit -m “Fixed #2125621: Contrast between title/slogan and header is too low.”  --author=“davidhernandez <davidhernandez@261131.no-reply.drupal.org>”

Followed by:

git notes --ref review append -m "davidhernandez <davidhernandez@261131.no-reply.drupal.org>, New Jersey Something Something <756332@756332.no-reply.drupal.org>"

git notes --ref accessibility append -m "mgifford <mgifford@782321.no-reply.drupal.org>, Open Concept <543211@543211.no-reply.drupal.org>"

git notes --ref review append -m "mparker17 <mparker17@1717171.no-reply.drupal.org>, Government of Canada <99999@99999.no-reply.drupal.org>, Whitehouse <00000@00000.no-reply.drupal.org>"

git notes --ref documentation append -m "jessebeach <jessebeach@27123.no-reply.drupal.org>, Acquia <21322@21322.no-reply.drupal.org>"

git notes --ref review append -m "anandps <anandps@123456.no-reply.drupal.org>"

Also please keep in mind that #2295411: Auto-generate Git attribution info / commit messages on Drupal.org will help to automate this so it would literally just be a copy and paste.

Re: --ref
I would imagine that a certain amount of this could be automated. For example, we could have a code namespace that would just detect the individuals that have uploaded patches. Crazy idea here, but we could perhaps put the "burden", so to speak, on the commenter and give the an option to choose which type of comment they are providing (i.e. code review, accessibility review, documentation review, patch, etc.). I would be more in favor of that personally as I am the one who knows what my true intentions are. Regardless, this is to just help the automated process. I suspect that in #2295411: Auto-generate Git attribution info / commit messages on Drupal.org we should still have the ability to manually alter the individuals attributed before copying and pasting the CLI commands.

Re: employers vs. customers
As far as I am aware, both of these are (or will be) just nodes. Regardless of the content type, they both contain nids. That is what I was saying is that the first entry is always a user (the person who provided the patch, review or whatever) and then any and all subsequent CSV "email" entries would be assumed nids to the respected entity.

I still feel strongly that not overloading the commit message and making a backwards-compatible format (with git notes) is more valuable than some nebulous hope that non-git projects will adopt our d.o-specific implementation and tool. Commit messages cannot be updated in the future, so we would have to add special-casing to parse our own git log if we changed the format. In contrast, git notes allow us to retroactively add/standardize credit while still using the git log we currently have.

metric ass-load of work on Version Control API

Huh? Where did someone familiar with Version Control API say this?

For the record, I agree with xjm that comment messages are a poor place for this info. If we get outvoted for some reason, then *please* put the actual text of what happenned at the beginning of the message. It is silly to put the bookeeping stuff beforehand. So,

"message. Issue #n by INDIVIDUAL@AGENCY*CUSTOMER:"

Sounds good. Adding tag.

Does the version control API have to be able to parse git notes for us to adopt a git notes format? Like, does adding notes break our existing parsing, or would it just be more work to richly integrate it both directions? If the latter, it seems we could add the notes generation from the start, and then do the other work later.

Does the version control API have to be able to parse git notes for us to adopt a git notes format?

I do not believe so, no. AFAIK, VCAPI doesn't actually parse the commit message at all currently. It just determines the committer and the author (--author) of the commit itself. This is why no one has contribution credit for core on their profiles aside those who have direct commit access, yes? Adding an additional layer to parse git notes doesn't sound like it would, in any way, conflict with existing code. It would simply be an additional event that is processed.

Can https://www.drupal.org/node/52287 be updated for things that are decided? Such as, moving "by …" to the end.

OK, based on #8 and #12, it does not look like we need to do much in order order to put contribution metadata into Notes. I suggest we go that way right from the start. If we don't, we're going to have angry devs who claim that we are using Git incorrectly.

As far as I can tell, this comes down to emitting two commands instead of one. We would emit git commit [STUFF] && git notes add [STUFF]

See also #2295411: Auto-generate Git attribution info / commit messages on Drupal.org. @webchick pointed out that we don't need to resolve this issue before adding that functionality, since adding the UI and the feature that already exists in dreditor could easily be the first step, followed by adopting a git notes format later.

I'm not sure which is the correct issue to post this on, there are at least three, however cross-posting my comment from #2230579-30: [meta] Allow crediting reviewers (and other non-coders) as first-class contributors

If we use git notes, since that can be edited without changing git history, I'd suggest the following:

1. We can auto-generate the message, and it'll be correct 95% of the time per #2295411: Auto-generate Git attribution info / commit messages on Drupal.org.

2. If we can auto-generate it, we can also have a script do this retrospectively for previous commits against core - as long as there's an issue nid associated with the commit that should be possible. That'd retrospectively fix some of the missing reviewer credit etc.

3. If we can auto-generate it, then I think the git notes part doesn't even necessarily have to be done by a core committer - we could automate it with a git commit hook, and then manually change things if we need to. Can always have the git commit hook not change anything if it's already there.

4. That leaves the current commit message - could remove attribution from that, or keep it to patch authors in the sense that's similar to what you'd see if we were merging pull requests.

I really think overloading the commit message is the wrong approach here - and it is going to add technical debt (in our commit messages of all things) for later parsing given it adds yet another format to deal with. Whereas with git notes we can potentially automate and back-date (and even change the format later and update that retrospectively too if we really needed to).

For Drupal.org, we aren't actually going to parse commit information. Since we will have the UI for generating it, we'll store it right away rather than re-parsing everything. (We can do a one-time reparse to get the history populated.) That storage isn't part of the first round of work, #2295411: Auto-generate Git attribution info / commit messages on Drupal.org. What Drupal.org stores as structured data (in fields) will be available in our RestWS API.

If this is a Drupal thing, the commit message isn't technically important in the end. It is good to visibly credit people. I'd expect 3rd-party parsing to use RestWS - JSON parsing will be more reliable than string parsing. You could query for credits to a person or organization right away, without building your own full database.

If this is a thing other non-Drupal Git users use.. we'll need Git community buy-in.

How is this a blocker for #2295411: Auto-generate Git attribution info / commit messages on Drupal.org? The goal isn't to fully implement the formatting. I am trying to be forward-looking in the formatting, moving by … to the end.

For Drupal.org, we aren't actually going to parse commit information. Since we will have the UI for generating it, we'll store it right away rather than re-parsing everything. (We can do a one-time reparse to get the history populated.)

Why would we do a one-time re-parse of commit messages (which are missing the full attribution information that this is supposed to add), rather than using the generation mechanism on older issues to populate the data set? Can't add companies for that but it can definitely help with issue openers, reviewers, issue summary updates, images posted etc.

It will be a one-off update closer to using the generation mechanism on older issues to populate the data set. Instead of a human using the form to populate the commit data, we'll parse it out of commit messages, stuff it into field(s) and save. Not a versioncontol module re-parse.

Added a new option: follow what linux and git project do.

So this issue is about the format for commit credit... where are we discussing where the data comes from/how to tell what company gets credit?

#1968480: Keep historical tracking of users' employers had good points on how we decide when to credit companies. The relevance here, is that we can't know what company a user worked for when they did work on an issue. We only know if "now" (on commit) they work for their "current" company.

This complicates seeding old data, and going back to old issues and filling in git notes.

It also makes the only choice a user has (if their employer does not give them time to work on issues) if they have spent their own time on issues, to make their current company a past company.

[edit: added the following]

Ah, there are good thoughts on the complication of this on the meta #2288727: [meta] Provide credit to organizations / customers who contribute to Drupal issues which has one option which suggests attribution with a UI on the issue at the time of each comment.

Yep, #2340363: Add issue comment attribution is likely the next issue to be implemented.

I gave it more thought over the weekend (and for months before that), and I really think we should go with option #1 over option #2.

$ git commit -m "Issue #42: fixed performance bug by Sam@Acquia, Megan, Tim*Pfizer."

Here is why:

• It is the easiest to use for committers which is critical for this to succeed.
• It is the easiest to read for people looking at commit messages. I personally don't subscribe to the idea that commit credits are metadata that should be hidden. I think it's really important information in our community. Almost all other Open Source projects store credit in the commit message too.
• It is the easiest to implement on Drupal.org.
• It is by far the most portable to other Git-hosting platforms and non-Git source code management systems.

All the other pros and cons are less important and if we are wrong, we can always change it later.

It is the easiest to use for committers which is critical for this to succeed.

It's not easier than git notes, which if automated would entail no changes at all for committers.

It is the easiest to implement on Drupal.org.

Impossible to retrospectively apply to older commits since it would require rewriting git history. While we can't do that for organisations, we can do it for issue authors, testers, reviewers etc. automatically.

I'm going to move this to core for the following reasons:

1. It affects the core code base.

2. It's a best practices change across all projects hosted on Drupal.org, and generally those get discussed in the core queue (at least for coding standards which commit messages are closest to).

3. #2230579: [meta] Allow crediting reviewers (and other non-coders) as first-class contributors is closely related and is already in the core queue.

One of the advantages of the git notes approach is that it separates the organisation - allowing both individual and organisations to stand on their own two feet. The ability to retrospectively credit people for reviewing an issue should not be discounted either. Getting good reviews on issues is one of our biggest problems and giving credit for it retrospectively could be massive.

since a key part of rolling all of this out is storing the credit in a database table of some kind which we can then utilize in Views, badges, etc. for both individual and organization profiles.

If the database table is retroactively populated based on different information to the commit messages in git, then it's going to be out of sync with what's in the codebase.

That means http://ericduran.github.io/drupalcores/, Certified to Rock etc. will either have to use the information from the database table on Drupal.org, or they'd be out of sync permanently with official data on Drupal.org

In that case, why does it have to be in the commit message at all? Why not just populate the table first with as much information as possible, then decide what if anything to reflect in git notes or the commit message later?

It's not easier than git notes, which if automated would entail no changes at all for committers.

It is easier than Git Notes for me. The argument might be subjective.

We can't truly rely on Git Notes as it is not supported in other source code management systems.

We could design the system such that it picks up the commit credit from the commit message *or* from the git notes.

It is easier than Git Notes for me. The argument might be subjective.

I don't think the ability to automate is a subjective argument. Either something is done entirely in the background so you don't have to interact with it, or it's not and you do.

We can't truly rely on Git Notes as it is not supported in other source code management systems.

Why is that a concern?

it requires the fewest changes to the existing workflows/infrastructure

By definition using the database only and nothing new in git would require less changes.

it's easily utilizable outside of Drupal.org as well.

That's simply not true if the information is outdated/out of sync compared to what's being used on Drupal.org

Regarding git commit message length:

1. git itself limits it to size_t. You are not going to be hitting that -- we are talking billions of characters at least.
2. In practice many tools (github for example) treat the first line as a "subject" and the rest as body.

I conclude: well formatted long messages are not a problem.

See for example http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-for... .

Oh and by the way, I absolutely love "Embed credit in commit message itself (another way)"

We could add Security-signed-off and Peformance-signed-off and UX-signed-off and so forth later which would make very ,very happy indeed.

"Embed credit in commit message itself (another way)" helps a lot on the format. i.e. if two people working for the same company and also in their own time contribute to an issue, the company gets one mention rather than two in the attribution.

Anything that happens with commit messages, we also need to remember that if we ever move to a merge flow, unless every merge is from a rebased branch with a single commit, the individual commit messages against the branch will also need to follow this format.

And also any issue for which there is more than one commit is going to run into problems, not just merges if there's a 1-1 correlation between commit message -> database field for the issue. alexpott decided last week he'd had enough of follow-up-patches-on-the-same-issue due to it messing meta-data (task vs. bug etc.). but that was only last week.

Making the field multiple value might work though?

I definitely agree with comment #18 that there are several related issues about this topic, and it is hard to discuss this since all of them are interconnected/interdependent.

First, some quick replies:

• Re #12: vcsapi git backend does not currently stores/recognizes any git-notes information, and it does indeed recognize both author and committer data associating them with users using by mail to do the mapping.
• Re #17: I do not see how github support is relevant here. We currently use two ways of showing commit messages, one inside drupal via vcsapi (does not currently support notes) and the other in our git web viewer, cgit (does support displaying of notes at least for default ref/notes/commits ref. Based on local testing it seems like it does not support custom refs, but I'm not sure yet)

Now, let me step back a little, hopefully this comment can add some more context to this issue.

On multiple authorship

Git allows only two internal representations of people associated with a a commit: author and commiter.

In Drupal community, changes are often worked by several people, so in order to give attribution to all of them we are using a Drupal convention to write commit messages since CVS times.
Currently in Drupal core, author and committer are used almost as synonymous, so we can "equally give credit" to several people, and only people with push access to the project should be the only ones in git author and committer data. It seems like all proposals does not change this.

I have been searching the git mailing list archives for information about assigning multiple authorship to one commit, but I only could find one relevant thread from 2012, How best to handle multiple-authorship commits in GIT?.
There, the main git maintainer proposes that author field should be taken only as a primary contact for a particular commit in case of question.

Based the mentioned Junio comment, the proposal for multiple authors in the git metadata itself will probably not be added to git in any near future, so we definitely should go with an alternative.

On granularity of contribution

As mentioned in comments #2, #3, #4, we would need to define if we would like to add additional information about what each contributor is helping with.
This naturally would need some manual analysis, since a tool cannot really automate this(at least for now).

This is valid for both 2nd and 3rd alternatives, which can either store information in different git-notes ref names or with different prefixes on each line.
First alternative just do not have that granularity.

In we decide to have this extra metadata, we should naturally need to define a set of git notes ref names or prefix keywords to use.

On extracting/showing attribution information

There are two components here:
A) Storing the attribution data
B) Mapping attributions to users in d.o

For step A:

• in-commit-message alternatives needs nothing since data is in git and both vcsapi and cgit shows commit messages.
• git notes alternatives needs vcsapi to be taught about reading git-notes(as mentioned in comment 20 item "2)") and cgit to be taught about non-default notes refs(if we decide to use a non-default ref), or both

For B, all mentioned alternatives require custom steps to actually map data either in commit or notes to d.o users.

Re #6-#7 (vcspi work needed for git-notes): I proposed a way to do it in #1282040-10: Add support for reading git-notes, and should be doable. Also see comment #12 there.

The Drupal.org engineering team met to talk through implementation a bit last week. We are in agreement that option 3 gives us the most direct way forward. (Option 3 is using commit messages, but separating contribution credits onto separate lines.)

Here are a couple of additional implementation details to work into the issue summary:

All credit will be associated with a commit rather than the issue. We will need to confirm that the commit entity (version control operation) that we store on Drupal.org can have fields, or other storage can be implemented cleanly. We can parse the users and organizations from the commit message, and associate them with the commit entity as user and node entity references.

We can use historical Git commit mentions to populate historical commit entities to give credit to individual contributors for past contributions. This should keep history in sync going forward. Because of the way that the supported-by element works, we can only track organization commit mentions going forward from the release of this feature.

Generating a commit credit from an issue will have a UI that allows the maintainer to select from contributors users and the organizations they have given credit. This will be important as the Git attribution format is specific. For an organization to have their contribution tied to their organization profile, they will need the maintainer to use the Git attribution email ID for that organization. For example...

Supported-by: Drupal Association drupal-association@1646370.org.no-reply.drupal.org

This is a representation of [Organization Node Title] [Organization Alias]@[Organization Node ID].org.no-reply.drupal.org.

A commit message will be generated automatically on the issue, so maintainers will not have to manually add IDs. For those that want to credit an organization in a workflow outside of Drupal.org, they will need to create an issue to easily tie together the commit credit to the associated commit. This is common practice—if not best practice—for most projects on Drupal.org. The upcoming issue workspace initiative will be an opportunity for us to look at workflows that pull in commits from external repositories such as GitHub.

The organization node ID is critical for successful parsing. Parsing based on an exact match with Organization Node Title is possible, but more prone to errors.

We will be able to use fields on the organization node to determine if the organization is a Drupal agency or a Drupal customer/end-user.

If there are no major disagreements remaining, I’d like to get this on my team’s schedule so that we can begin collecting these credits for future display. Can we put a time box around remaining comments to be added between now and the end of the year with a final decision by that time? That will allow us to begin implementation the first week of 2015.

We started with three primary goals for crediting individuals and organizations:

1. Give credit to the funders of work in the community. The hope is that exposing this credit will give companies incentive to give back more.
2. Study how the community works, by studying the relationships between customers, agencies, and volunteer contributions and how and where the money is flowing.
3. Clearly identify "teams" of people who work for the same employer/customer (and thus raise potential conflicts of interest on controversial issues)

To this we are adding the following requirements for issue credits:

1. Credit is given on Drupal.org. We recognize the ecosystem is growing to include repositories on GitHub, and even private repositories, but the canonical repositories live on Drupal.org for projects that can call home to update services. Further, user and organization profiles for Drupal community members are on Drupal.org.
2. Credits should be given at the issue level for organizations and individuals. This will allow us to give first-class credit for non-code issue contributions. (We are also exploring non-issue credits separately for contributions such as event sponsorship, documentation, answering support requests, etc.)

With these principles in mind, we are going to shift our focus to #2288727: [meta] Provide credit to organizations / customers who contribute to Drupal issues and work on the UI for a user to give credit to an organization and for maintainers to award the credits to contributors.

Once this UI is ready, we will begin storing credit at the issue level. This will allow us to collect data that can be used for making decisions about how credits are displayed on user profiles and organization profiles.

As we will not need to parse data from the commit message with this solution, we will come back to the commit credit format after we have a couple months of credit data.

Contributed-by: Sascha Grossenbacher <berdir@214652.no-reply.drupal.org> (@MD Systems, *Drupal Association) # sponsored by Drupal Association D8 accelerate fund
.....
Contributed-by: Alex Pott <alexpott@157725.no-reply.drupal.org> (!volunteer, @Chapter Three, *Some Other Mysterious Drupal 8 Client)

(Note, that looks like a huge mess. I started without using special symbols but wasn't sure how to delineate "I work for the DA" from "I was sponsored by the DA." Hmmm.)

Yeah, I agree. Way too many symbols :)

With what I just proposed at #2288727-67: [meta] Provide credit to organizations / customers who contribute to Drupal issues this would be a lot simpler, I think, and easy to delineate the differences. It could become something like this:

Contributed-by: Sascha Grossenbacher <berdir@214652.no-reply.drupal.org> (@MD Systems#employer, @Drupal Association#contractor)
.....
Contributed-by: Alex Pott <alexpott@157725.no-reply.drupal.org> (#volunteer, @Chapter Three#employer, @Some Other Mysterious Drupal 8 Client#client)

Or maybe "contractor" in the first would be "sponsor" instead - but the point is (a) it's definitely not "employer"; there'd be a defined list to choose from (and it would be easy to add or subtract from that list when necessary), and (b) you only need two symbols, not four :)

Question: With any of the proposals above, how does a module maintainer give credit to an organization, assuming their work to maintain the module is being sponsored by an employer or client?

Would they have to put their own name into the commit message for every patch they review and commit?

Or would we just assume that this never goes into Git (and the organization only gets credit on the project page instead)?

For contrib maintainers, the project's supporting organizations do show on the organization pages today. I'd say that should stay higher on the page than issue credits, since supporting a project is a bigger deal. Each maintainer is free to credit individual issues however they wish. We can provide the UI and advice on using it, but each project is its own project in the end.

This was postponed in #55 in December.
Given the progress on #2340363: Add issue comment attribution,
and that #2369159: Extend crediting UI to include organizations & customers will be / is starting,
do we want to
make this active again,
and,
- figure out the format here, so 2369159 can use it,
- or, let 2369159 work on the table and have a separate issue to implement whatever is decided here?

Oh, #56 @joshuami

As we will not need to parse data from the commit message with this solution, we will come back to the commit credit format after we have a couple months of credit data.

So, then the intention was to NOT change the commit messages right away.
Updating the issue summary with my guess at what this is postponed on.

I think we can go ahead and make this active. We need to refine the format to specifically map to the data we're starting to collect in the other issues. Some of these questions might have been answered in comments already, we should get them into the issue summary.

Currently, the issue summary has a list of users, then a list of companies, with no user → organization → customer mapping. Is that okay? Would ordering the lines "user, company, customer, repeat" be better?

Both organizations and customers are put in Supported-by: Is that okay? Is there a more-appropriate header?

Do these same formats apply just as well to contrib?

What if we grouped them by contributor with a new line in between each grouping? That would keep the format similar and leave open the option for someone to visually scan the git log or parse it for the same data we are storing in the database.

I believe issue credits will be a more accurate view of organizational contribution than commit logs, but I want to recognize the need to keep the history in git for flexibility in the future.

All of this looks great. But for contrib modules, most of the time being able to give someone full credit for a patch they provide is enough, and there has been a regression on d.o in losing the copy-paste help to give direct attribution to a commit (e.g. --author="joe_user <joe_user@123456.no-reply.drupal.org>" as described on this documentation page. It's possible to construct this author attribution manually, but a) it's quite inconvenient and b) people who had opted out of the no-reply e-mail attribution to use an e-mail address they use for git attribution in other places no longer have that preference honored. I don't see anything in this discussion that suggests a policy change from --author credit, indeed it's used repeatedly in examples, so would loss of the --author attribution line from profiles be a bug that should be fixed?

... and now i see, as i post this, that the "Credit & committing" section will provide the --author line. I merely scoured documentation, went on IRC where no one hanging out happened to know about it, and wrote this whole comment before seeing. Updating documentation now!

The loss of using a real e-mail in attribution does appear to have been lost, however. Is that an unintended regression?

This is all tangential to --author. That will still be available as radio buttons in Credit & committing, and this changes what the checkboxes will do. Each project maintainer can give out credit as they see fit.

The related conversation in #2474609: Not possible to credit people who didn't comment in an issue reminded me that we might need a little clarification around assigning org credits outside of Drupal.org.

In comment 56 of this thread, we had decided that we would only record credits related to canonical issues or commits on Drupal.org. While users can track intent in commit messages on GitHub or private repos, we cannot parse those repos. We are relying on the maintainer/committer to the Drupal.org repo to include information in the commit for us to recognize that as credit we should track.

Ideally, relationships between issues and commits on D.o repos are be best practice. That gives us a place to store the credits and tie back all of the data to the D.o organization and D.o user. Can we require that every commit is related to an issue so that we can capture the data in an issue credit?

Any other ideas for how we store parsed data from commit messages?

I think the need for a mirrored repo on D.o is a minimum requirement. Every username and organization name is very specific to Drupal.org or we cannot map it to a canonical entity to add it all up and show on a profile. The same applies to GitHub. You don't see commit frequency for a user unless that repo is on GitHub and matches to the user on GitHub. I wonder how the tool that makes it easy for a GitHub commit to get the necessary username and organization data and pull that in would work? Would we need to work with GitHub on an integration between our user accounts to make that happen easily?

With commit message parsing, do we end up keeping a two tier system? Issue credits expanded the notion of "contributor" to be anyone that participated in the comment thread. It also allowed users to explicitly show their organizational attribution intent for each comment. When that intent is summarized into an issue credit, you see users and organizations getting one credit per issue they helped resolve. So multiple commits on an issue still equate to one issue credit awarded by the maintainer that pulls that work into the final repo.

Commit mentions are per commit. Will parsing commit mentions into a data structure lead to a greater number of total credits per user or organization based on frequency of commit versus issue? Do we only count commits to the project head? I would imagine the git commit history for an internal project that gets packaged up to publish on Drupal.org looks really different than the commit history for Drupal core.

I'm trying to wrap my head around that part. It is so important to how we can display the resulting data and weigh its meaning.

So many questions... sorry about that.

A couple refinements from what Angie said.

1. I would think that we would be able to affiliate the commit with a d.o. user via any recognized email address, no just the no-reply email addresses. So, Contributed-by: Moshe Weitzman would affiliate with me. It is onerous to require use of d.o. emails"
2. I would like to move the Issue #2183983: to later in the Commit message as it gets in the way when you can single line commit summaries. I know that habits are hard to change, but we can do it. So:

git commit -m 'Find hidden configuration schema issue. Issue #2183983.
Contributed-by: Gábor Hojsty 
Contributed-by: Vijayachandran Mani 
Contributed-by: Wim Leers 
Contributed-by: Sascha Grossenbacher 
Contributed-by: Florian Weber 
Contributed-by: Alex Pott 


Supported-by: Acquia 
Supported-by: Capgemini 
Supported-by: MD Systems 
Supported-by: UEBERBIT GmbH 
Supported-by: Chapter Three 


Supported-by: Some Mysterious Drupal 8 Client 
Supported-by: Some Other Mysterious Drupal 8 Client 
'

Google has open sourced Git Appraise - a distributed code review application that stores its data in Git Notes. I'd say that Notes are robust enough to handle our metadata needs.

Also to add that git notes was proposed on one of the very first discussions around this back in 2011: https://groups.drupal.org/node/161659

Now that we handle issue credits on drupal.org itself instead of git can we close this issue?

Somewhat related to the git message format aspect discussed here: #2802947: [meta] Use the Git commit message format from AngularJS

There are a few suggested improvements to the credit system from Dries' recent blog that suggest we may still want to consider this issue.

The credit system gives us quantifiable data about where our community's contributions come from, but that data is not perfect. Here are a few suggested improvements:

1. We need to find ways to recognize non-code contributions as well as code contributions outside of Drupal.org (i.e. on GitHub). Lots of people and organizations spend hundreds of hours putting together local events, writing documentation, translating Drupal, mentoring new contributors, and more—and none of that gets captured by the credit system.
2. We'd benefit by finding a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might have gotten a credit for 30 minutes of work. We could, for example, consider the issue credit data in conjunction with Git commit data regarding insertions, deletions, and files changed.

Source: http://buytaert.net/who-sponsors-drupal-development

Bump: #2972225: Move from opt in to opt out for contribution attribution is now live on d.o. :/ That's going to make our bad problem *much* worse. Can we please prioritize coming to a decision here so we can move the credit to the end of the commit template?

My only suggestion to the template in the summary is that instead of using "Issue" all the time, why not add value to those bytes and use the 1-word version of the category? Like so:

Bug #3029061: New layouts are missing config schema
...
Task #3027938: Abstract the contents of LayoutBuilderController into a render element
...
Feature #3015886: Add an in-memory config storage
...
Docs #xxxx: Fixed PHPDoc for whatever.
...

This is not a new idea, it's been proposed elsewhere/before (e.g. #2802947-29: [meta] Use the Git commit message format from AngularJS), but I haven't seen it discussed in here.

Meta: There are a lot of related issues swimming around here. Is this the parent/meta for them all? Where's the right place to actually have the debate, finalize a decision, and implement it?

Thanks!
-Derek

See also #2811033: Discuss if git commit messages should be multiple lines. Do we need to refactor all of this into a unified meta? There's a ton of overlap between these two issues.

Bumping to NR.

Thanks!
-Derek

I think we need one issue, not sure which one, maybe a new one altogether with references to the duplicates. The issue credit system is implemented on Drupal.org and doesn't rely on parsing commit messages so most of the discussion here is very out of date now.

Somewhere... not sure if it's in the issue queue, there's a proposal to rely on https://www.conventionalcommits.org/en/v1.0.0/ which seems worth exploring.

Yes please, https://www.conventionalcommits.org/en/v1.0.0/#summary is exactly the Angular git commit format I proposed 7 years ago in #2802947: [meta] Use the Git commit message format from AngularJS. Happy to see they made a specification out of it!

It's very likely that we will not keep a version of the commit/merge UI we have on Drupal.org issues when upgrading Drupal.org. The recommended way to do a merge will be using the merge button in GitLab. That almost certainly won’t support a list of usernames like we have now. Git trailers, like mentioned in conventional commits, are likely to have some support. I suspect we may have to do something special to get people who helped the issue, but didn't participate in the MR, mentioned. Ideally, we find a way to forward Drupal.org credit data into GitLab's default merge request commit message.

https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates.... has a few options, with varying degrees of hackiness:

When the maintainer saves issue credit:

• We could make a MR comment authored by each credited person who hasn't made an MR comment, to update %{reviewed_by}
• We could make an empty commit authored by each credited person who hasn't made a commit, to update %{co_authored_by}
• We could reset approvals and say every credited person approved, to update %{approved_by}
• We could rewrite a commit message on the branch being merged
• We could update the MR description to update %{description}

Those are all somewhat non-ideal in various ways. I'd probably choose updating the MR description over the others; and start spreading the message that the MR title & description is the place to make a draft commit message.

Or, we decouple commit message mentions from issue credit and don’t worry about having them (mostly) match.

[edit]As the systems are really decoupled, I’d totally agree with the latter suggestion.[/edit]

We could build in the new system a message suggestion that could be copy/pasted into the MR description if desired, otherwise give freedom to do any commit message since the credits are decoupled from it.

Yes, catch is right this needs a new issue for discussion. I have created #3439331: [policy] Decide on format of commit message for that. And as he pointed out much of the discussion here was about credit and that is now outdated.

I am not sure if this should be Closed as fixed or outdated. Someone else may know and I will think about that. In the meantime I am setting to RTBC.

Hmm there was useful discussion here, but we never changed the commit message format - credit was implemented purely on the d.o side and commit messages remained the same. I think we should close it as outdated (original intention was done but in a very different way), and move onto the issue to actually improve the commit message format which @quietone linked.