1 |
Alec Warner posted on Wed, 21 Mar 2018 10:44:48 -0400 as excerpted: |
2 |
|
3 |
> On Wed, Mar 21, 2018 at 1:36 AM, Eray Aslan <eras@g.o> wrote: |
4 |
> |
5 |
>> On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote: |
6 |
>> > While I personally do no agree with mailing list moderation infra has |
7 |
>> > been tasked with moving forward on it. |
8 |
>> |
9 |
>> You can always resign from infra. |
10 |
>> |
11 |
>> |
12 |
>> That was a somewhat tongue-in-cheek comment but not wholly. You cant |
13 |
>> cop out by saying it was an order from council. I understand if you |
14 |
>> dont but do consider it. Fight the good fight. |
15 |
>> |
16 |
>> |
17 |
> So when there is conflict its pretty often that you have 3 options. |
18 |
> |
19 |
> 1) Accept 2) Leave 3) Escalate |
20 |
|
21 |
Wise words. |
22 |
|
23 |
Here the context was/is infra, but they apply to general devs and users |
24 |
who disagree with this as well, thus my own personal interest, altho I'm |
25 |
not so much a "disagree" as a "concerned and sad it has to come to this", |
26 |
as I see both sides. |
27 |
|
28 |
[Note: I intend this to be my only post to this thread, unless a reply |
29 |
calls for further reply on my part. It's my position of record on the |
30 |
moderation/whitelisting and may also be my last to the list before it |
31 |
goes moderated. If that's not of interest to you I'd rather you skip the |
32 |
rest of the post and use the time for something you consider more |
33 |
constructive. =:^) ] |
34 |
|
35 |
> I'm not sure 3 is possible (the council is already the highest body). I |
36 |
> also think that as a organization this is how we arranged it to be. |
37 |
|
38 |
Astute observation. |
39 |
|
40 |
> Speaking for myself, this is not the worst issue I've seen in Gentoo and |
41 |
> so I thing doing 2 is probably not very effective. Its also likely I can |
42 |
> only do 2 once (because maybe I would not be welcome'd back or want to |
43 |
> contribute anymore.) |
44 |
|
45 |
Also astute. |
46 |
|
47 |
I'm ignoring my urge to point to "real world" examples as this list is |
48 |
*definitely* not the place, but in the safer general realm it can simply |
49 |
be observed that there's /always/ a leave/stay-and-accept (if only |
50 |
temporarily/strategically) argument to be made, even in the /worst/ cases |
51 |
(which must here be left to imagination and history) where arguably |
52 |
"leave" is the only morally acceptable alternative. |
53 |
|
54 |
Fortunately, I believe most will agree this isn't a "worst" case in that |
55 |
regard, tho it may be bad enough that some find they must leave. |
56 |
|
57 |
But for both users and devs there remain the practical questions: |
58 |
|
59 |
Where else would I go? Is that alternative actually practically viable? |
60 |
Would I be more effective there than here, hoping to eventually reverse |
61 |
the decision (or for those like me more on the sad-it-came-to-this-but-I- |
62 |
see-why-some-believe-it-has side, hoping a short trial is demonstration |
63 |
enough of capacity and that it lowers the threat to where even those that |
64 |
agree it has to come to that now feel comfortable in reverting it, tho |
65 |
possibly retaining the capacity to reimpliment if necessary)? |
66 |
|
67 |
In practice, there are certainly from-source alternatives. However, |
68 |
again practically, gentoo does seem to be the biggest, and most others |
69 |
seem to either be mostly-compatible offshoots such as funtoo and exherbo |
70 |
that to some degree still depend on the larger gentoo tree and community, |
71 |
or to make choices that put them to one side or the other of gentoo's |
72 |
"automated/scripted from-source" approach (arch's core-binary approach on |
73 |
the toward-binaries side, and lfs/linux-from-scratch's much more manual- |
74 |
but-still-guided, approach on the other). |
75 |
|
76 |
There's also the very practical "but I already know and am familiar with |
77 |
gentoo and how it works (both technically and socially) and would have to |
78 |
learn the others" factor. |
79 |
|
80 |
For both those reasons and I suppose others, gentooers who have been |
81 |
around a few years, at least long enough to develop that familiarity, |
82 |
tend to stay around as long as they remain interested in gentoo's general |
83 |
automated-from-source approach (tho many ultimately lose that interest |
84 |
and go binary-distro or leave the FLOSS community entirely), unless of |
85 |
course forced out as incompatible with continuing community interest, in |
86 |
which case, given little choice, they often land at one of those |
87 |
alternatives. |
88 |
|
89 |
> That leaves 1 and one interests me for many reasons. |
90 |
> |
91 |
> a) as noted earlier, decisions are not set in stone. Its possible we |
92 |
> could turn on this whitelisting solution for a brief period and the |
93 |
> decision is overturned at the next council meeting, or perhaps at the |
94 |
> next council election once the existing council is replaced. |
95 |
|
96 |
Agreed. I've already mentioned what I believe would be my ideal outcome, |
97 |
above. Try the whitelisting as proposed for awhile, then having |
98 |
demonstrated the capacity/threat, relax things, while maintaining the |
99 |
capacity, such that hopefully the toxic people that created the initial |
100 |
need will not find it worth their while to be toxic here once again, but |
101 |
with the capacity to reinstitute should they do so. |
102 |
|
103 |
(Yes, I know that unused tools fall into disrepair over time, but often, |
104 |
repair, or even redo if necessary, is easier the second time around. So |
105 |
hopefully the capacity would remain available or at least easier to |
106 |
implement again, if again needed.) |
107 |
|
108 |
(Points B and C omitted as infra specific, because I've nothing to add.) |
109 |
|
110 |
> d) Infra as a organization wields a lot of power in Gentoo and I think |
111 |
> its organizationally dangerous to wield that power in this way. [...] |
112 |
> e) In the past, infra *has* wielded its power in a fashion that had |
113 |
> negative impacts on the distribution (e.g. arbitrarily removing commit |
114 |
> rights for developers with no warning, process, or oversight). |
115 |
|
116 |
Having lived thru much of that, I 100% agree that it's not something |
117 |
gentoo should ever want to go back to. While individuals are certainly |
118 |
free to resign should they feel the need, having even infra subject to an |
119 |
_elected_ council is a _good_ thing! |
120 |
|
121 |
|
122 |
Meanwhile, I've already stated my position. I'm sad to see it come to |
123 |
this, and hope it to be eventually reversed, but the elected council has |
124 |
spoken, I understand the events that lead to their decision, and remain |
125 |
and abide is my chosen option. |
126 |
|
127 |
And as for the effect on my own posts as a non-dev, personally... |
128 |
|
129 |
* My posting intent on any list, including this one, is positive |
130 |
contribution. Should I ever believe my posts have ceased to be that, |
131 |
I'll immediately apologize if it was one-off/short-term, or stop posting |
132 |
if I don't believe my posts to be a positive contribution going forward. |
133 |
|
134 |
(I've often spent quite some time composing a post, only to ultimately |
135 |
close the window without sending, because on consideration before hitting |
136 |
send, I decided it wasn't unquestionably a positive contribution to the |
137 |
list/discussion in question. Sometimes just writing it for me was what I |
138 |
needed to do. Sometimes I simply thought better of it, period.) |
139 |
|
140 |
* I'm acutely mindful of the fact that this _is_ gentoo-*dev*, and that |
141 |
as a user, not a dev, I'm but a guest here. |
142 |
|
143 |
(And yes, that sometimes influences my "don't send it after all" |
144 |
decision.) |
145 |
|
146 |
* While there are complaints of my verbosity, I've never been /banned/ |
147 |
and I'm proud of that. |
148 |
|
149 |
* I've had personal offers to whitelist, for which I am grateful. |
150 |
|
151 |
(The given reason was that while I'm often too wordy, I often do have a |
152 |
valid point/question, that may not have been brought up by others. I do |
153 |
struggle with the wordiness, believe me, but I'm grateful that at least |
154 |
some devs consider my posts a positive enough contribution to extend the |
155 |
whitelisting offer.) |
156 |
|
157 |
* For the time being, I've thanked, but turned down that whitelisting |
158 |
offer. When I'd otherwise post, I'm going to take the opportunity to |
159 |
reconsider the positive contribution of my posts even more, try again to |
160 |
whittle down the wordiness further, and then, if I still consider it |
161 |
worth the effort, I'm going to forward the post to the person I'm |
162 |
replying to or possibly to someone else (like the person who offered the |
163 |
whitelisting), asking them to forward it... but *only* if they too |
164 |
consider it a positive contribution to the current discussion. |
165 |
|
166 |
Tho I may eventually request whitelisting, in the mean time I intend to |
167 |
learn what I can from the forward/rejection/rejection-with-feedback on |
168 |
those attempted contributions, to try to make future attempted |
169 |
contributions even better! =:^) |
170 |
|
171 |
That's keeping in mind that as a user not a dev, I /do/ consider myself a |
172 |
guest on this list, and arguably, posting to it has /always/ been a |
173 |
privilege, not a right. And given the coming whitelisting, devs, thru |
174 |
their elected council, have clearly expressed their desire to cut down |
175 |
the outside noise from "guests", ensuring that any such "guest posts" |
176 |
allowed thru are signal, not noise, or worse yet, negative signal. |
177 |
|
178 |
As one of those guests, abiding by that expressed intent to the best of |
179 |
my ability is my goal, and I intend to take the presented opportunity to |
180 |
try to improve my own attempts at contribution! |
181 |
|
182 |
-- |
183 |
Duncan - List replies preferred. No HTML msgs. |
184 |
"Every nonfree program has a lord, a master -- |
185 |
and if you use the program, he is your master." Richard Stallman |