> > My blunt opinion would be that we should never take over changes. The > point of an open source community like Apache Guacamole is > collaboration. There's a big difference between a contribution from a > contributor who is working together with the existing development > community for the benefit of all, vs. abandoned code in a basket on > the project's doorstep. The latter is essentially a contribution of > technical debt, and ultimately harmful if accepted in that form. > > We should definitely give all contributors the benefit of the doubt > here, and there's no reason to assume that they intended to abandon > the changes, but closing stalled PR's is not a bad thing. Just as with > a JIRA issue where the reporter has ceased responding, closing things > just acknowledges that the issue is not moving forward, and allows the > community to refocus on other matters. If the contributor comes back, > then things can be reopened. If not, then there really is no > contribution, and we should just move forward as we normally would. > > - Mike >
Mike, I'm sorry. I must be driving you nuts at this point, and I'm not trying to do that. Really :-). I'm not entirely sure I understand what you mean by technical debt. What I'm trying to do, though, is to figure out a way to recognize people's contributions even when they do abandon those changes. My suggestion of forking an (apparently) abandoned pull request, completing it, and then closing out both the new and the old request is specifically so that people's contributions of code are recognized and so that I'm not blatantly ripping off work that someone else has done with commits under my name. So, if for no other reason than to help me understand, let's approach this question a different way. Let's take GUACAMOLE-243 and focus on that one, specifically. There's a bug in Guacamole, in the guacamole-auth-ldap extension, in the way that it handles LDAP referrals. This bug needs to be fixed - it's a particularly frustrating bug for people using Active Directory, and, while we don't get the question every day, there have been several instances of people on the mailing list wondering why they can't query their AD servers for users, and then someone responds pointing them to the global catalog (or non-global-catalog - I can never keep it straight). So, clearly a bug, and clearly needs to be fixed. Adam contributed some code that takes care of the issue. He got the code almost all the way completed, minus a couple of minor tweaks that need to happen in debug logging, but hasn't responded to the pull request thread in months. As I see it, in this case, your statement, "...there really is no contribution, and we should just move forward as we normally would" could mean the following things: 1) Close the PR, leaving the bug unfixed. 2) Close the PR, and completely ignore the previous commits, but fix the code, probably using code that the person has already written, but without giving them any credit for their work. 3) Close the PR, ignore the previous commits, and try to find a way that's "different enough" so as to avoid the appearance of plagiarizing someone else's work. Or do you mean something else that I'm missing here? To me, the first option isn't practical, because the bug needs to be fixed. The second option seems like the kind of thing that is going to discourage participation in the development process, because it gives off the vibe that the Guacamole project is willing to plagiarize work - passing code that others have written off as our own. The third option seems impractical, because, first, the way they implemented it might actually be the best method, and, second, after you've reviewed someone's code, it's difficult (and silly) to try to pretend like you have no knowledge of that code, or to try to code it differently just because you do have knowledge of it. My suggestion for forking the pull request and completing it was not aimed at "taking over" someone else's work, but was aimed at striking a balance between recognizing that someone had put some time and effort into solving a problem and had written some code that works and is good code, and recognizing that, for one or more of many reasons, that person has apparently decided not to see that contribution through to completion. I'm also not trying to "codify" anything - I'm not saying we should come up with a policy, or that we should assume that people aren't going to complete things they begin to contribute. I want to give people the benefit of the doubt and I want to encourage more contributions to the project, particularly by committed, engaged, active developers. So, is there a way you want to handle these particular stalled PRs? Again, I'm not saying across the board, but, taking GUACAMOLE-243, which represents a bug that needs to be fixed, are you suggestion we just close the PR, drop all of the commits, and start fixing it, again, from scratch? Similar question for the SSH key size issue. That's more of a feature than a bug (slightly), but the changes there are so straight-forward that it isn't like we can just pretend we haven't been through the process of changing that once, already. Are we just going to close that PR and introduce a brand new PR with those modifications, as if the first PR never existed? Again, I'm sorry - I'm trying to understand what direction to go, here, in order to further the development of Guacamole as a community project - one that recognizes contributions, that has a growing community, and that is improving in stability, security and functionality. I'm definitely not trying to force my direction or viewpoint here - I'm asking for guidance on how to approach these issues in a way that doesn't ignore past contributions, but that recognizes that these issues need to be fixed. -Nick
