Hi Marc and Andrea, On Sat, 23 Aug 2025 at 07:45, Marc Haber <mh+debian-de...@zugschlus.de> wrote: > On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote: ... > >This is not the end of the world, but I wanted to share it as an > >anecdote of the new contributor experience. > > As a package maintainer, I am not very fond of the idea of having to > jump through hoops just to make sure that the bug submitter is mentioned > everywhere possible and gets the proper statistics, badges, chocolates > and hugs. If that means more work for me, I'll probably take the short > and easy way for me while still being polite according to my time > budget.
I did not ask anyone to "jump through hoops". I simply asked people to review open Merge Requests, which implies giving the MR a chance to get accepted instead of just getting ignored. If you are lucky, the submission is good and you merge it, which is the happy path and minimal amount of work. If it is not good, it is up to your judgement to decide how much you spend time on giving feedback and onboarding a new potential collaborator. About the statistics my point was just that *if* you accept a contribution the way git was designed to be used (either via UI or command-line), and the contributor has their name at least in the git "Author" field (your name can be in the "Committer" if you want) everythng that follows about stats and credits is automatic. On Sat, 23 Aug 2025 at 08:00, Andrea Bolognani <e...@kiyuko.org> wrote: > On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote: > > On Sun, 17 Aug 2025 at 19:33, Theodore Ts'o <ty...@mit.edu> wrote: ... > > So all the effort the submitter did - and also me as mentor - was in > > vain. This is not the end of the world, but I wanted to share it as an > > anecdote of the new contributor experience. > > I find it quite interesting that you would qualify this as a wasted > effort on the mentee's part and your own. > > This implies that the primary goal when opening the MR was getting > the person's name into the Debian changelog / git log, not improving > Debian or gaining experience in how to contribute. So it sounds to me > like your perception of the outcome was heavily influenced by the > initial framing. No, it does not imply. Actually I find it quite demotivating having spent extensive amounts of time improving Debian in various ways that somebody writes on debian-devel@ that my goal is *not improving Debian*. Please don't write such things. Instead assume good faith and think about what the positive interpretation would be in case I didn't write clearly enough. Try to think about it from the contributor's point of view: if you spend time debugging something and produce and submit a fix, and it gets accepted, you as the submitter can be sure that you really helped improve Debian, and all the effort you did in testing and documenting your fix was read by somebody, approved and incorporated into the software. However, if do all this work and discover that the first reply on your MR was it being closed, there is no validation that you helped improve Debian. The maintainer might have seen and copied your code, or the maintainer might have investigated and fixed it on their own, in which case all your efforts were in vain. But you don't know. While the visibility part of getting credits is nice, it is certainly not the goal, just a part of it. The main benefit from getting your contribution in is validation that you indeed did something that was sufficiently good to get accepted and valuable to Debian, and it will strengthen your confidence to repeat the same next time you run into a bug. > With that said, I fully appreciate that visibility is currency when > it comes to FLOSS and I agree with Jonas that maintainers should > credit contributors even if not merging their changes exactly as > proposed. See [1] for a recent example of me going out of my way to > ensure that the contributor gets full credit for their work. > > > [1] https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/274 Thanks, this is a great example of the happy path. Accepting the contribution surely saved you time compared to doing the Turkish translations yourself, the submitter is likely to do more translations with this positive experience, and also if you use `gbp dch --release` before upload the contributor will automatically be credited in the debian/changelog based on having his name in the git history now.
