Also recognize "Co-authored-by" contributions

[haraldreingruber]

We are running monthly Mob-Programming meetups and would like to run also a Hacktoberfest special. As all commits/PRs are crafted as a team/mob, the co-authors are attributed using this feature of Github Desktop: https://desktop.github.com/features/co-authors/

It would be awesome if the co-author's contributions would be recognized as well for the Hacktoberfest challenge.

Github Desktop just adds one or more “Co-authored-by” trailers to the end of the commit message:
https://github.blog/2018-01-29-commit-together-with-co-authors/

PS Here is the link to our meetup, just in case you would like to find out more about our events: https://www.meetup.com/Mob-Programming-on-Open-Source-Software/

[devil-cyber]

Can you provide some insight about this issue o want to work on this

[MattIPv4]

Fwiw, I'd probably hold off on working on this. We (DigitalOcean) are likely going to build out a new app from the ground-up for next year to encompass requests such as this and those asking for multi-provider support.

For context on what's involved in this issue though, we'd likely need a way to update the PR fetching logic we use to also fetch the merge commit for any PR during Hacktoberfest that has been merged. This is a good way to limit the scope on commits we're fetching whilst capturing all the commits that will be co-authored from a PR.

Once you've got those merge commits, we then would need to detect valid co-authors on those commits, and tie that merge commit to the users in Hacktoberfest that have signed up. We'd need a new data model here to store the merge commit (similar to how we store PRs) and to tie it (or the originating PR) to multiple users.

Possibly the most sensible way to do this is to essentially tie the originating PR back to each user so that we can use the existing logic for the review period and state transitions etc. with the merge commit only being used to tie that PR to multiple authors.

As I said though, this is a complex issue and probably not worth working on with this codebase as this isn't something we'd merge for Hacktoberfest 2020 (don't want to modify business logic now that the event is underway) and we'll likely be building out a fresh codebase for Hacktoberfest 2021.

[haraldreingruber]

Hi @MattIPv4, thanks again for the constructive feedback last year.

I wanted to check back if it makes sense to include this feature request for this year's hacktoberfest release?
Hacktoberfest is such a great initiative, it would be really great if Mob-Programming contrbutions could also get acknowledged.

Thanks,
Harald

[MattIPv4]

👋 I've been working on the new codebase for the last few months, and I don't really think it'll be logical to attempt to track additional authors on PRs -- GitHub's GraphQL API tentatively reveals this data from a pull request through the associated merge commit & git actors, but this will also include the user who merged the PR as they're also appended to the Co-authors list by default, and you cannot directly access pull requests based on this association as a PR is still only ever tied to the original author that opened the PR. In GitLab land, their GraphQL API does not reveal this data at all by default, so would require us to attempt to manually fetch commits on each repo, which I feel is ultimately out-of-scope here.