Gentoo Archives: gentoo-project

From: Daniel Campbell <zlg@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly
Date: Mon, 23 Jan 2017 09:01:36
Message-Id: cbd65188-21b7-01f1-f182-d89358a84aa1@gentoo.org
In Reply to: Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly by "William L. Thomson Jr."
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

Attachments

File name MIME type
signature.asc application/pgp-signature