1 |
On 12/14/2013 12:50 AM, Chris Reffett wrote: |
2 |
> Hello all, |
3 |
> |
4 |
> As a member of the GLEP team, I would like to propose several |
5 |
> updates to GLEP 1. I have attached the original and diffs for each of my |
6 |
> proposed changes for reference, and I apologize in advance if any of the |
7 |
> diffs cannot be applied simultaneously. Summaries and rationales for |
8 |
> each change are as follows: |
9 |
> |
10 |
> 1. Remove the "current GLEP editor" list. I don't see a reason to update |
11 |
> this every time the GLEP editor roster changes, and this can be found on |
12 |
> the website/Wiki/other places. |
13 |
> |
14 |
> 2. Allow GLEPs to go to gentoo-project. In the year and a half I've been |
15 |
> a dev, pretty much all GLEP-related discussion I've seen has stuck to |
16 |
> the usual rule of technical stuff on -dev, non-technical on -project, |
17 |
> despite GLEP 1 saying all GLEP discussion should go to -dev. This |
18 |
> actually puts that rule into GLEP 1, saying that Standards Track GLEPs |
19 |
> (which are for the most part technical in nature) go to -dev, and |
20 |
> Informational (which are generally non-technical) go to -project. |
21 |
> |
22 |
> 3. Here's where we start changing workflow. I would like to be more open |
23 |
> about the GLEP approval/rejection process, and that starts with the |
24 |
> proposals. I would like to change from the format of "email glep@ -> |
25 |
> only the submitter and the GLEP editors know of all of the proposals and |
26 |
> rejection rationales" to a more transparent system, and that system will |
27 |
> be bugzie. This change would have people submit prospective GLEPs on |
28 |
> bugzilla, and the editors will discuss and approve/reject there. This |
29 |
> also provides for suggesting major changes to GLEPs on bugzilla. This |
30 |
> change would be supported by adding a GLEP product and "New GLEP" and |
31 |
> "GLEP Update" components on bugzilla (though the specifics here can be |
32 |
> flexible, if preferred it could go under Doc Other, for example). |
33 |
> Alternatively, we can have people comment on the original GLEP bugs when |
34 |
> they have changes (like how we handle new dev/retirement bugs), but I |
35 |
> feel this method is better for compartmentalizing changes. |
36 |
> |
37 |
> 4. It is unclear in the current GLEP 1 wording whether changes need to |
38 |
> go through the Council. Going from the example of the recent changes to |
39 |
> GLEP 48 going through the council, this adds clarification by saying |
40 |
> that anything that actually changes the meaning of the GLEP should go |
41 |
> through the Council. |
42 |
> |
43 |
> 5. This removes GuideXML as a GLEP format. Currently, no GLEPs are in |
44 |
> GuideXML format, and since we are migrating away from hosting project |
45 |
> stuff on www.gentoo.org anyway there is no need to continue supporting |
46 |
> GuideXML as an option. This particular change was suggested by a3li. |
47 |
> |
48 |
> 6. The other big workflow change, this would make the official storage |
49 |
> of GLEPs move to the Wiki, under the GLEP: namespace, which would be |
50 |
> restricted to GLEP editors (since, obviously, we don't want people |
51 |
> messing around with the GLEPs). This also makes the official GLEP format |
52 |
> change to Wiki markup from the current ReST format. If this one receives |
53 |
> a generally positive consensus, I will present an updated GLEP 2 redone |
54 |
> in Wiki markup to the Council along with these proposed changes, and |
55 |
> would handle the conversion of existing GLEPs to Wiki markup. |
56 |
> Alternatively, we could probably find a plugin for MediaWiki to handle |
57 |
> pages in ReST format, and so not have to change the official format. |
58 |
> Either is acceptable to me. |
59 |
> |
60 |
> I am definitely open to other approaches, so in addition to the usual |
61 |
> criticisms of the proposal, please let me know if you can think of a |
62 |
> more efficient workflow for the GLEP process. My goal is to make the |
63 |
> GLEP process easy for everyone and as transparent as possible. |
64 |
> |
65 |
> Thanks, |
66 |
> Chris Reffett |
67 |
> |
68 |
A couple more changes: |
69 |
6. Further edits: Changed the header section. Strip a lot of the |
70 |
headers, most of the header stuff will be handled on the wiki in an |
71 |
infobox/as metadata. The header will now just keep the bare minimum of |
72 |
info, and that will all be input to the wiki by the GLEP editor. |
73 |
|
74 |
7. This one was ulm's suggestion. Change required license from public |
75 |
domain/OPL to CC-BY-SA 3.0 to be consistent with the wiki. Public domain |
76 |
GLEPs will be relicensed as they are moved to the wiki (since the wiki |
77 |
transition needs some reformatting done anyway, might as well, and |
78 |
public domain means that we don't need author permission). OPL may stay |
79 |
as they are since they require us to track the original authors down for |
80 |
permission, but it is recommended that they be converted with authors' |
81 |
consent. |
82 |
|
83 |
Chris Reffett |