1 |
On 01/22/2017 08:27 AM, William L. Thomson Jr. wrote: |
2 |
> On Saturday, January 21, 2017 11:27:49 PM EST Daniel Campbell wrote: |
3 |
>> |
4 |
>> |
5 |
>> Agreed. If there's interest in growing Gentoo, it should be Gentoo |
6 |
>> developers who care enough about it to do something, |
7 |
> |
8 |
> Then why isn't Gentoo growing? For a very long time now. |
9 |
> |
10 |
> This attitude that Gentoo is its developers is VERY wrong. There is allot that |
11 |
> comes from the community. Most developers started as members of the community. |
12 |
> |
13 |
> Gentoo developers are NOT the only ones who do the work. They are not the only |
14 |
> ones who care, and at times some would say they are the ones allowing neglect. |
15 |
> Gentoo Developers have a proven track record of only carrying about things |
16 |
> that are of interest to them. NOT Gentoo over all, big difference. |
17 |
|
18 |
You're right; Gentoo developers aren't the only ones doing work. The |
19 |
Gentoo community is similar to other libre software communities in that |
20 |
they help each other in support channels, they write tutorials and/or |
21 |
tools for use with the distro, they talk about it in other fora, and |
22 |
sometimes bring more people to the distro. This produces a lot of |
23 |
positive for Gentoo, but at the core of it it's only us (the developers) |
24 |
who can really change Gentoo as an entire distribution. We decide |
25 |
policy, we decide QA, we decide whether infra stays up. I'm not |
26 |
advocating that we *abuse* that power, but a common reason we become |
27 |
developers is that we've proven we can contribute positively to Gentoo |
28 |
and know enough about the structure to know how things get done, even if |
29 |
it's a process we don't agree with. That's a hassle for some people, and |
30 |
I fully understand that. |
31 |
|
32 |
On the matter of only working on things that interest us, I think that's |
33 |
slightly too simplistic. It's natural to work on things that interest |
34 |
us, but that's coupled with an attitude of safety. I can't speak for |
35 |
other developers, but I don't want to work on something I'm not |
36 |
knowledgeable and competent in. What little time I get to devote to |
37 |
Gentoo, I'd rather contribute in ways that I'm (more) competent in, so I |
38 |
don't create more work for others. Naturally, that's going to look like |
39 |
someone's avoiding work, but the "why" really matters here. I get the |
40 |
feeling that I'm not alone in that sentiment. Now, that also means I |
41 |
might not learn as much as I could. I think I'd be hurting Gentoo if I |
42 |
used it as my personal self-education without respect for the processes |
43 |
and practices that allowed Gentoo -- and by extension my developer-hood |
44 |
-- to be possible. So that's why a safety-first approach to things |
45 |
generally works for collaborative environments. It slows things down, |
46 |
yes. But it also tends to break a little less often as a result. If that |
47 |
style doesn't match with someone, that someone would be happier and more |
48 |
productive in another distro or another project type entirely (one that |
49 |
doesn't have such myriad requirements for interoperability and technical |
50 |
compatibility -- things that an OS needs to care about). |
51 |
|
52 |
If the community takes matters into its own hands and decides they'll be |
53 |
the face of Gentoo, well... legally they can't do that. The foundation |
54 |
owns the trademark. But they can fork it, and many have. Some believe |
55 |
that's reason for concern. In some ways they're right: it *should* be a |
56 |
little concerning to learn when we get a new fork, because it shows us |
57 |
that there's a problem with Gentoo -- one so great that somebody said, |
58 |
"screw it, I'll make my own, with blackjack and hookers." [0] We should |
59 |
be seeking these forks and learning from them, so that -- if the |
60 |
reasoning behind a given fork is compelling to our interests -- we can |
61 |
either find a way to work better with that fork, or change things so |
62 |
that a fork isn't necessary in the first place. The recent RFC |
63 |
concerning distribution variables from Galapagos Linux is an example of |
64 |
ways we can work *with* our forks rather than against them. |
65 |
|
66 |
Forking in general isn't necessarily a bug, though. It's as much a |
67 |
feature of libre software as libre licenses are, and is the foundation |
68 |
of the Bazaar model. Those that make up a group need to be able to |
69 |
maintain their work should the fish start rotting from the head, so to |
70 |
speak. So with that said, please don't interpret my words as being |
71 |
against forks. I think they're good, and sometimes necessary. But we can |
72 |
and should learn from them where possible. |
73 |
|
74 |
> |
75 |
>> like maffblaster |
76 |
>> who started/resurrected the gentoo-news project. *That* is something |
77 |
>> that could engage the community and keep people up-to-date on what's |
78 |
>> going on. |
79 |
> |
80 |
> Yes as it did before and the GWN and even monthly ended for a reason. |
81 |
|
82 |
What reason do you think that is? Not meant to be sarcastic; I'm |
83 |
honestly interested. We should discuss that in a different thread, |
84 |
however, so please feel free to open a new one or find the Gentoo News |
85 |
thread, where that may be more relevant. |
86 |
|
87 |
> |
88 |
>> Naturally, it'll need more developers to be involved, but |
89 |
>> every large thing started out small, so it has tons of room to grow. |
90 |
> |
91 |
> Really interesting how you start with saying it will take developers, then end |
92 |
> with saying it needs more developers.. |
93 |
|
94 |
Well, you're right, adding more people to a project doesn't |
95 |
automatically fix things. It comes with project management overhead, |
96 |
even more people who aren't on the same page, etc. Adding mandatory |
97 |
reporting could throw a serious wrench into our workflows, because we |
98 |
already have trouble getting developers to run repoman or other helpful |
99 |
tools that assist us in producing a better distribution, or OpenPGP key |
100 |
compliance, signed manifests and commits, etc. |
101 |
|
102 |
In short, there's no shortage of problems to fix within Gentoo, and |
103 |
holding that back with what amounts to paperwork isn't going to fix it. |
104 |
The work itself needs to be done. Direction for said work is important, |
105 |
too, which is why Gentoo has a metastructure that allows for projects |
106 |
and the leads for those projects. Assuming a project isn't violating QA |
107 |
guidelines/policy and isn't causing a ton of work for others, they're |
108 |
pretty much free to govern how they see fit. Most from what I can tell |
109 |
are very informal, to facilitate simple and clear communication. I think |
110 |
what you're advocating for is really just better leadership. Gentoo |
111 |
won't get that until we get people who want to lead and care enough |
112 |
about Gentoo to make it happen. We need to vote people in who we believe |
113 |
see enough of the big picture to kinda nudge things in the right |
114 |
direction, but enough gritty details to make educated decisions when the |
115 |
vote on agenda minutes or make judgment calls on disputes. |
116 |
|
117 |
That's all Gentoo-land stuff, however. It's stuff that the community on |
118 |
its own doesn't have the power to do. So it comes down to us and the |
119 |
people we vote in. If our metastructure is suffering, if recruitment is |
120 |
down, if we're not on top of things, blame lies squarely with us, the |
121 |
developers. We should be more conscientious in our voting and look for |
122 |
ways to improve our wetware when possible. But that must be tempered |
123 |
with real work, too. What good is electing someone if they don't do what |
124 |
they say? What use is it to become a developer if you then do nothing? |
125 |
(note: I'm semi-guilty of that at times) |
126 |
|
127 |
I guess what I'm saying is words and actions should go together. When |
128 |
they don't we should fix it. We don't need weeks-long discussions stuck |
129 |
in analysis paralysis. If it's important, write an RFC, get it on the |
130 |
agenda, and have people make decisions on it. It's what they were voted |
131 |
in for, after all. In my limited experience with things like that, I've |
132 |
learned that if someone makes a lot of noise about something but doesn't |
133 |
back it up with a proposed solution (RFC) and real action (bringing it |
134 |
before council to vote), then maybe that person didn't care enough. I've |
135 |
been guilty of that, too, mostly when I was using other distributions. I |
136 |
learned a lot when I became a dev here, and most of it boils down to |
137 |
age-old wisdom: actions speak louder than words. |
138 |
> |
139 |
>> Making this thing or that thing mandatory adds to the already protracted |
140 |
>> processes of our structure. It's an idea that sounds good in general but |
141 |
>> when applied to our context (non-profit, volunteer work), it doesn't work. |
142 |
> |
143 |
> I like how something not tired is known not to work. Go look around your |
144 |
> community. Find a non profit or volunteer somewhere. See if you are not |
145 |
> required to do stuff. |
146 |
> |
147 |
> People need to get past this volunteer npo BS. It is an excuse not reality!!! |
148 |
> |
149 |
|
150 |
With that logic, we should try literally every metastructure or |
151 |
policy-set possible before we settle on one that works Good Enoughâ„¢. |
152 |
Perfect is the enemy of good, after all. |
153 |
|
154 |
Requirements in the physical world are applied in a different manner |
155 |
because it is separate from the digital world. Reporting requirements |
156 |
and other bureaucracy work in in-person organizations that have clear |
157 |
and distinct goal. Our work in general is to develop and maintain |
158 |
Gentoo, which means different things to different people. So rather than |
159 |
adopt a strict process, groups are allowed to form and disperse |
160 |
naturally and informally. This is inefficient if the goal is to get as |
161 |
much development done as possible, but it's much more efficient for |
162 |
*humans*. Too much order and control is mechanical; not enough is a |
163 |
free-for-all. There's no harm in letting developers work on what they |
164 |
find interesting. For the gaps, it's a sign that we need to find people |
165 |
who enjoy Gentoo enough and are knowledgeable enough in those |
166 |
categories, and see if they're up for becoming developers. |
167 |
|
168 |
That's not *required*, however, because git is a thing. Someone who |
169 |
wants to help Gentoo generally *can*. Nothing related to our processes |
170 |
stops a person from `git pull`ing, hacking, and contacting a developer |
171 |
to get something put in. We credit contributions, too. The project needs |
172 |
*some* sort of gate keepers to watch over the infra and primary |
173 |
development. Naturally, these people are called developers. |
174 |
|
175 |
tldr: Mandatory reporting == paperwork, and is unneeded overhead. |
176 |
|
177 |
[0] I hope it's obvious this particular quote is a joke, but you can't |
178 |
be too sure over text. |
179 |
-- |
180 |
Daniel Campbell - Gentoo Developer |
181 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
182 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |