Add glep 54, to replace (and require) glep 39, regarding project announcements and RFCs. I'm marking this as F (final) as it was approved ages ago; feel free to take up wording and merits with me and it will be edited after the fact. If you have a problem with this process, again take it up with me as I'm the bastard that did it. Thanks

1

GLEP: 39

2

Title: An "old-school" metastructure proposal with "boot for being a slacker"

3

Version: $Revision: 1.2 $

4

Last-Modified: $Date: 2006/02/09 21:53:54 $

5

Author: Grant Goodyear <g2boojum@gentoo.org>,

6

Ciaran McCreesh <ciaranm@gentoo.org>,

7

Status: Accepted

8

Type: Informational

9

Content-Type: text/x-rst

10

Created: 01-Sep-2005

11

Replaced-By: 54

12

Post-History: 01-Sep-2005, 09-Feb-2006

13

14

15

Status

16

======

17

18

Implemented. GLEP amended on 09 Feb 2006 to add the final bullet point to

19

list B in `Specification`_.

20

21

Abstract

22

========

23

24

GLEP 4 is replaced with a new "metastructure" that retains established

25

projects (and makes new projects easier to create), but adds a new "Gentoo

26

Council" to handle global (cross-project) issues.

27

28

Motivation

29

==========

30

31

The Fosdem and subsequent reform proposals shepherded by Koon are thorough,

32

extremely detailed, and somewhat complicated. They have a lot of good ideas.

33

For many who have been with Gentoo a long time, though, there's just something

34

about them that they don't really like. More than a few Gentoo devs are

35

almost entirely uninterested in metastructure as long as it doesn't get in

36

their way, and because the current proposals impose at least some order on our

37

unruly devs these proposals are guaranteed to "get in the way" to some degree.

38

For example, a frequent comment that has been heard is that many Gentoo devs

39

don't know who his/her manager (or project lead) is, which is a clear

40

indication that our current system is broken. The existing proposals solve

41

the problem by requiring that each dev belong to a project. Perhaps the part

42

that is broken, though, is the belief that every dev should have a manager.

43

The history of Gentoo is such that traditionally big advances have often been

44

implemented by a single or a small number of dedicated devs (thus our

45

long-standing tradition that devs have access to the entire tree), and surely

46

we do not want to make things harder (or less fun) for such people. So here's

47

a minimal proposal for those who remembers the "good ol' days" and thinks

48

things aren't really so different now.

49

50

Synopsis of the current system:

51

52

* There are 13-15 top-level projects (TLPs). Top-level projects are

53

comprised of sub-projects, and the goal was that every Gentoo

54

project would be a sub-project of one of the TLPs. Supposedly each

55

dev therefore belongs to one or more TLPs.

56

* Each TLP has at least a "strategic" manager, and potentially also an

57

"operational" manager. Only the strategic managers vote on global

58

Gentoo issues.

59

* The managers of each TLP were appointed by drobbins, the other

60

TLP managers, or elected by their project members. These managers

61

have no set term.

62

* Within each TLP the managers are responsible for making decisions

63

about the project, defining clear goals, roadmaps, and timelines

64

for the project, and solving problems that arise within the TLP

65

(see GLEP 4 for the specific list).

66

* The strategic TLP managers are also responsible for deciding issues that

67

affect Gentoo across project lines. The primary mechanism for

68

handling global-scope issues is the managers' meetings.

69

* Disciplinary action taken against erring devs is handled by the

70

"devrel" TLP, unless the dev is a strategic TLP manager. In that

71

case disciplinary action must be enacted by the other strategic TLP

72

managers.

73

74

Problems with the existing system:

75

76

1. The assumption that TLPs are complete is either incorrect (there

77

still is no "server" TLP) or just plain weird (but the lack of a

78

server TLP is technically okay because all devs who don't have an

79

obvious TLP belong to the "base" TLP by default).

80

2. There is nothing at all to ensure that project leads actually do

81

represent the devs they supposedly lead or satisfy their

82

responsibilities. Indeed, should a TLP manager go AWOL it is not at

83

all obvious how the situation should be resolved.

84

3. Nothing is being decided at global scope right now. Some TLP strategic

85

managers rarely attend the managers' meetings, and the managers as a

86

whole certainly are not providing any sort of global vision for

87

Gentoo right now.

88

4. Even if the strategic TLP managers were making global decisions for

89

Gentoo, the TLP structure is such that almost all devs fall under

90

only one or two TLPs. Thus voting on global issues is hardly

91

proportional, and thus many devs feel disenfranchised.

92

5. Regardless of whether or not it is justified, devrel is loathed by

93

many in its enforcement role.

94

95

Here's a couple of additional problems identified by the current

96

metastructure reform proposals:

97

98

6. The current system has no mechanism for identifying either projects

99

or devs that have gone inactive.

100

7. Bugs that cut across projects often remain unresolved.

101

8. GLEPs often linger in an undetermined state.

102

103

Specification

104

=============

105

106

107

A. A project is a group of developers working towards a goal (or a set

108

of goals).

109

110

* A project exists if it has a web page at

111

www.g.o/proj/en/whatever that is maintained. ("Maintained" means

112

that the information on the page is factually correct and not

113

out-of-date.) If the webpage isn't maintained, it is presumed dead.

114

* It may have one or many leads, and the leads are

115

selected by the members of the project. This selection must

116

occur at least once every 12 months, and may occur at any

117

time.

118

* It may have zero or more sub-projects. Sub-projects are

119

just projects that provide some additional structure, and their

120

web pages are in the project's space.

121

* Not everything (or everyone) needs a project.

122

* Projects need not be long-term.

123

* Projects may well conflict with other projects. That's okay.

124

* Any dev may create a new project just by creating a new page

125

(or, more realistically, directory and page) in

126

``gentoo/xml/htdocs/proj/en``.

127

128

B. Global issues will be decided by an elected Gentoo council.

129

130

* There will be a set number of council members. (For the

131

first election that number was set to 7 by acclamation.)

132

* Council members will be chosen by a general election of all

133

devs once per year.

134

* The council must hold an open meeting at least once per month.

135

* Council decisions are by majority vote of those who show up (or

136

their proxies).

137

* If a council member (or their appointed proxy) fails to show up for

138

two consecutive meetings, they are marked as a slacker.

139

* If a council member who has been marked a slacker misses any further

140

meeting (or their appointed proxy doesn't show up), they lose their

141

position and a new election is held to replace that person. The newly

142

elected council member gets a 'reduced' term so that the yearly

143

elections still elect a full group.

144

* Council members who have previously been booted for excessive slacking

145

may stand for future elections, including the election for their

146

replacement. They should, however, justify their slackerness, and

147

should expect to have it pointed out if they don't do so themselves.

148

* The 'slacker' marker is reset when a member is elected.

149

* If any meeting has less than 50% attendance by council members, a new

150

election for *all* places must be held within a month. The 'one year'

151

is then reset from that point.

152

* Disciplinary actions may be appealed to the council.

153

* A proxy must not be an existing council member, and any single person

154

may not be a proxy for more than one council member at any given

155

meeting.

156

157

Rationale

158

=========

159

160

So, does this proposal solve any of the previously-mentioned problems?

161

162

1. There is no longer any requirement that the project structure be

163

complete. Some devs work on very specific parts of the tree, while

164

some work on practically everything; neither should be shoehorned into

165

an ad-hoc project structure. Moreover, it should be easy to create new