Richard Brown wrote:
In the case of Carlos I would actually describe him as 'actively not contributing', as he was aggressively pushing the argument that Tumbleweed COULD NOT be translated..)
I thought Tumbleweed was to only use translations to Sanskrit, Babylonian, or Phonecian (or maybe that was some bad dream), but if someone saw the issue as similar, they might really feel it COULD NOT be translated. I very much got a similar opinion about any discussion concerning *various* tangential issues to the mandate of the new boot process. Why my DISPLAY and/or all my env vars needed to be cleared when I "sudo'd" or "su"d from a remote session -- or why the "pam_session" module, designed to be called once/session, was being called in the middle of my login session and wiping my ENV vars (killing remote displays) was completely opaque to me. I felt they COULD NOT usurp it's previous role, but they did. Many people have complained on this list about how remote logins, in various forms (RDP/remoteX) no longer working as more requirements for "SuperBoot" went into the code base. So I COULD NOT see how many things, similarly related (or obviated by the new superbooter) could be done while keeping any compatibility. Eventually I got that compatibility was not on the requirement list and was actually frowned upon, as it might allow or encourage people to not convert to the new system𝐝 way of doing things. So I can easily understand someone thinking & saying that something "COULD NOT" be done. I certainly don't see that as a reason to ban something (though some people apparently do). It certainly seems out of place and intolerant for an international gnu-*nux-software based discussion forum (where unix has ALWAYS had more than 1 way of doing things, vs. Windows or Mac -- where choices are more often limited to 1 or 0).
It was discussed long before, but some of those "old contributors" effectively blocked the idea via bikeshedding
One person's bikeshedding is another's compatibility.
It's an unfortunate fact of open source life that discussion only has a limited impact, where as 'action' defines where the Project goes. In this case, the Weblate contributors decided, based on previous experience, that instead of discussing first, then doing, they would do first then discuss
This is not ideal, and I criticised it in the threads I suggested you read, but given the circumstances I do find it understandable
That is the lesson of "those who do, decide".
Those who "do" have permissions and authority to do. Those who aren't able or are locked out of the "do" process get no option to decide or the option for any input at all. That's called a dictatorship.
at the end of the day what matters most is that contributors contribute and that those contributors have nothing in their way from contributing.
Where contributors are defined by those who concur with the dictatorship and are given access and ability to contribute.
You cannot 'manage' volunteers. We do not hire, fire, or assign tasks to individuals.
But you can ban them or not give them access to make changes.
We cannot force people to do what they are ordered.
Eh? Someone told Carlos that he couldn't even contribute on mailing lists, let alone in the project (because he didn't feel he could use the new tools to get the job done). Personal example: rm can no longer be used, stand-alone to delete all files in a directory that are only on the same file system as the starting directory. Used to be you could do "rm -fr foobar/.", or my even more paranoid variation, "cd foobar/. && rm -fr .". The "do'ers" decided to vote in a code-exception to how rm's depth-first removal operatated -- and enforce a top-down check pass based on various exclusions, one of which is not allowing any filename == "." to be included in the 2nd pass of removing files (rm does 2 passes now to remove files -- one to find the files to delete/exclude & 2nd to actually do the "unlink"). I offered patches, and was told they would not be allowed. Those who are not allowed to contribute can't be "do'ers". Same went for the perl-project, where I was suggesting and arguing for simplifications and a more optimized language to support new users in learning and using perl in a backwards compatible way. Unfortunately, making perl cleaner, easier to learn and understand ranked right about where compatibility on the new sysboot project. I was "nurtured" to no longer post and or participate in perl5 maintenance and development. Since then, multiple incompatible feature changes have gone into the code (without prior warning) that cause me to have to rewrite code -- and generally retain perl 5.16.3 for normal system maintenance. Some of the code that needed rewriting dated back to perl4 days. Amusingly enough, while some of my suggestions were regarded as being backwards incompatible Ex. "printf" can take an array as an argument and use the 1st member as the format and take args from the rest of the array as needed. "sprintf" will throw a syntax error if you don't specify the format statement separately from the arguments. As a new feature in 5.22.x, while it has always been the case that sufficient arguments were needed to satisfy the format statement, it has never been the case where that number was also used as the *maximum* number of args allowed. So where I used to have "sprintf $fmt, $scalar" (where scalars also hold references to arrays, hashes and such), I had a case statement choosing how to print the scalar based on its type. For arrays and hashes, I printed contents down to some default depth (w/the default being override-able), and then printed [...] or {...}. In those cases, sprintf now regards the list as having too many arguments for the "format" statement and throws a diagnostic. This leads to the the new perl paradigm with better line-noise of adding "%.0s" to the strings were no vars would be referenced. Perl's "line-noise" reputation didn't happen by accident -- it's a feature!
In terms of people management, the best we can do is direct, support, and nurture.
Yeah, as if kicking people off lists and permanent bans are real supportive and nurturing -- baloney! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org