On 02/13/20 03:10, Michał Górny wrote: > On Wed, 2020-02-12 at 23:03 -0800, Alec Warner wrote: >> On Wed, Feb 12, 2020 at 9:59 PM Michał Górny <[email protected]> wrote: >> >>> On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote: >>>> Hi, >>>> >>>> thank you for bringing this to the list. >>>> >>>> I have the same experience which is the reason why I haven't migrated >>>> most of my packages yet (which is not a good move because I also didn't >>>> post the problem to the list like I wanted *yet*, I only talked to >>>> people via private mail, chat or at FOSDEM about that and was working on >>>> a proposal I wanted to show next week when I am hopefully healthy again). >>>> >>> >>> In other words, instead of bringing the problem up to the person who >>> created the GLEP and the eclasses and/or community at large, you've been >>> conspiring behind their back. Yes, that's really the procommunity >>> attitude we expect from Council members. Thanks for showing it again. >>> >> >> This is a bit of a double standard. Either people are 'conspiring behind >> your back' or they 'are gathering data for a counterproposal.' There is no >> need to paint a negative narrative here. >> > > Yes, I certainly do have a reason to assume positive from someone who > apparently mounts a counterproposal without bothering to consider > the original reasons. > Given that we have already established that you cannot distinguish between technical feedback and personal attacks, consider this a "teachable moment".
You have not been personally attacked in this thread. Someone has posted commentary critical of something you were involved in. Yes, you expended significant time and effort in that project but it is the fruits of the project, not your personal integrity, competence, sanity, nor preference in ice cream that are being called into question. There is no call for smearing the other party, just conversing with them, evaluating their arguments as they evaluate yours and reaching a mutual understanding of each other's perspectives and issues as they relate to the project at hand. If they have concerns which the project does not adequately address in its current form, the implementation can be improved; if their concerns are adequately addressed by an improved understanding of the implementation as it exists now, then at the least you will have discovered where the documentation could be improved. Note that I am not in any way opining upon the project or implementation itself as that is immaterial to my point.
