1 |
On Tue, Jan 27, 2009 at 12:17 AM, AllenJB <gentoo-lists@××××××××××.uk> wrote: |
2 |
> Alec Warner wrote: |
3 |
>> |
4 |
>> On Mon, Jan 26, 2009 at 1:30 PM, AllenJB <gentoo-lists@××××××××××.uk> |
5 |
>> wrote: |
6 |
>>> |
7 |
>>> Hi all, |
8 |
>>> |
9 |
>>> The Gentoo PR Project currently appears to be having difficulties with |
10 |
>>> keeping up, both with the newsletters and announcements, and I believe |
11 |
>>> this |
12 |
>>> is currently reflecting badly on the project as a whole. These issues are |
13 |
>>> apparently holding back some key changes to the Gentoo website to make it |
14 |
>>> easier to navigate and help the project appear more active than is |
15 |
>>> reflected |
16 |
>>> by the current front page. |
17 |
>>> |
18 |
>>> If the project needs more hands, and these aren't appearing, then perhaps |
19 |
>>> more should be done to advertise the positions and exactly what they |
20 |
>>> entail |
21 |
>>> (I would suggest announcements on the forums, with specifics on who to |
22 |
>>> talk |
23 |
>>> to for those interested). |
24 |
>>> |
25 |
>>> The newsletter has been having issues for some time, and this makes me |
26 |
>>> wonder if the amount of effort required is excessive for the value |
27 |
>>> obtained |
28 |
>>> from those efforts. While the GuideXML system Gentoo uses for |
29 |
>>> newsletters, |
30 |
>>> etc is nice, does it require too much time and effort to convert articles |
31 |
>>> to |
32 |
>>> GuideXML and get the newsletters published? |
33 |
>> |
34 |
>> So you go on to describe issues with thew Newsletter. |
35 |
>> |
36 |
>> What kind of issues? |
37 |
>> Is there not enough content? |
38 |
> |
39 |
> At the moment the newsletter isn't getting published at all. If this is |
40 |
> because there's not enough content being submitted, then I think more needs |
41 |
> to be done to encourage submissions and/or actively seek out and write |
42 |
> articles. |
43 |
> |
44 |
> This comes back to the number of editors the newsletter currently has, which |
45 |
> is influenced by the skills required to work on the newsletter (currently |
46 |
> CVS, GuideXML and knowledge of the scripts used to generate standard |
47 |
> content). |
48 |
> |
49 |
|
50 |
So in short, we have no idea why the newsletter has not been published. |
51 |
|
52 |
Lets ask the GMN folks (added to the CC) as I am curious as well. |
53 |
|
54 |
>> Is GuideXML in fact a barrier for submission (do we get complaints about |
55 |
>> it?) |
56 |
> |
57 |
> If there isn't enough content being submitted to actually produce one, then |
58 |
> tell the community this. As said above, perhaps mroe needs to be done to |
59 |
> actively seek out and create content. |
60 |
> |
61 |
|
62 |
sounds good; I agree we need to be more vocal here. |
63 |
|
64 |
>> Are there insufficient translators? |
65 |
> |
66 |
> I can't see that translators is an issue, because even the English version |
67 |
> isn't getting published. |
68 |
> |
69 |
>> Are the editors not posting content quick enough? |
70 |
>> Are the editors editing properly? |
71 |
>> Are there enough posters in general? |
72 |
>> |
73 |
>>> Alternative setups for the newsletter could be to either go text-only or |
74 |
>>> web-only. |
75 |
>>> |
76 |
>>> Text-only would involved producing a text-only email, which is then |
77 |
>>> copied |
78 |
>>> and pasted onto the website for archiving. This would obviously require |
79 |
>>> minimal formatting work. |
80 |
>> |
81 |
>> Ok, but if the problems are with finding material; changing how the |
82 |
>> material is posted will not help. |
83 |
> |
84 |
> The idea behind this was to reproduce the amount of work involved in taking |
85 |
> a plain text submission (which I would guess is the form most submissions |
86 |
> come in) and getting it published in the newsletter. This method removes the |
87 |
> need for conversion to GuideXML. |
88 |
|
89 |
Hrm, I assume s/reproduce/reduce/ here. I personally think |
90 |
transcribing the text to guideXML is a fairly simple process and y'all |
91 |
are a bunch of whiners (and I am too; work has HTML documentation and |
92 |
it sucks). But its what we have and it works fairly well and I think |
93 |
a lot of folks are annoyed when people pop in to redesign everything. |
94 |
We resist change ;) |
95 |
|
96 |
> |
97 |
>> |
98 |
>>> My idea for a web-only setup would require more initial work, but I think |
99 |
>>> would make maintenance much easier once set up. The Gentoo Newsletter |
100 |
>>> would |
101 |
>>> become a separate website, not based on GuideXML, but on a standard CMS. |
102 |
>>> Instead of having set release dates (weekly or monthly), articles would |
103 |
>>> just |
104 |
>>> be released as soon as they are produced. |
105 |
>> |
106 |
>> Why does a new shiny CMS enable this? Certainly we could provide |
107 |
>> access to news/ to a broader audience? |
108 |
>> You seem to think the target audience cannot author GuideXML though. |
109 |
>> |
110 |
>>> The regular features like bug stats, GLSAs, developer changes could be |
111 |
>>> easily generated automatically (I suspect almost all of those are mostly |
112 |
>>> done automatically anyway - adapting such scripts for a CMS that can |
113 |
>>> publish |
114 |
>>> from RSS feeds should be relatively trivial) and would appear on the |
115 |
>>> website |
116 |
>>> without any intervention. |
117 |
>> |
118 |
>> This is covered by index2; so I'll ignore it ;) |
119 |
> |
120 |
> You're assuming index2 ever goes live. From what I've seen it's been hanging |
121 |
> around for at least 6 months in a "ready to go live" state, so I'm not |
122 |
> holding any hopes of this happening any time soon. =P |
123 |
|
124 |
Getting Index2 live is I think a different operational issue (that |
125 |
changes to the website are very slow) |
126 |
and really has nothing to do with PR aside from them not nagging |
127 |
someone to commit it ;) |
128 |
|
129 |
>> |
130 |
>>> As above, articles would be published as and when they are ready. Instead |
131 |
>>> of |
132 |
>>> just 1 editor, this website-based setup would be able to have multiple |
133 |
>>> editors with little collaboration required (just to mark submissions as |
134 |
>>> being worked on when an editor picks them up, which should be easily |
135 |
>>> doable |
136 |
>>> using a ticket-based system (bugzilla) or mailing list). |
137 |
>> |
138 |
>> Does the current news have only 1 editor? I am on PR but I tend not |
139 |
>> to commit news or approve things. |
140 |
> |
141 |
> Why do you not tend to commit news or approve things? |
142 |
|
143 |
PR@ is a nghtmare of spam and what I'll term 'crap.' having real |
144 |
things marked as such with informative subjects would be useful. |
145 |
having some kind of rotation would be useful |
146 |
having some kind of vague 'we will read and respond within 3 days |
147 |
unless its a holiday' would be useful. |
148 |
|
149 |
Right now the expectations of pr@ are non-existent and apparently |
150 |
think the mail is read and answered quickly. In reality only Donnie |
151 |
reads it and replies; he has a busy as hell personal life and I'm |
152 |
surprised he manages to read it at all. |
153 |
|
154 |
So I would like to set expectations ;) |
155 |
|
156 |
> |
157 |
> It may not be just the 1 editor, but I suspect the problem is a general lack |
158 |
> of active editors. From what I've read, current GMN publishers require |
159 |
> knowledge of how to run all the scripts to generate the standard content and |
160 |
> write GuideXML to a pretty good standard. I suspect this is all quite time |
161 |
> consuming (from the little I've done in GuideXML, I certainly find that time |
162 |
> consuming). |
163 |
> |
164 |
> This suggestion would: |
165 |
> 1) Drop the skill requirements for news article publishers to being able to |
166 |
> operate a CMS |
167 |
> |
168 |
|
169 |
So if I promised news to be published within 3 days; would that cut it for you? |
170 |
|
171 |
> 2) Require minimum collaboration between multiple editors, allowing the |
172 |
> number of editors to be easily increased. Inactivity shouldn't be an issue |
173 |
> in this system, because no single editor is responsible for collecting |
174 |
> everything together and publishing. |
175 |
|
176 |
Arguably no single editor should be responsible in the current system either. |
177 |
|
178 |
There 10 people (excluding infra) who have access to commit to main/ |
179 |
|
180 |
Obviously we have the wrong 10 since 9 of them (including me) don't |
181 |
seem to be doing much ;) |
182 |
|
183 |
> |
184 |
>> |
185 |
>> I would propose an alternative alias or subject tag that will single |
186 |
>> your post request out from the other trash that gets sent to pr@; that |
187 |
>> way it might actually receive some attention. |
188 |
>> |
189 |
>>> An advantage, as I see it, of the website-based system is that it could |
190 |
>>> be |
191 |
>>> expanded to include features not currently easily possible with the |
192 |
>>> current |
193 |
>>> newsletter - categorized archiving of articles (not just be publish date) |
194 |
>>> and user comments. While I haven't looked, it's probably possible to even |
195 |
>>> find a CMS which includes email notification of new articles as a |
196 |
>>> feature. |
197 |
>> |
198 |
>> This is a bad sell; we could certainly expand the current one as well |
199 |
>> (with cool new features!) except we have no staff for that (in either |
200 |
>> system). Talk about what you will do; not what you plan to do in the |
201 |
>> nefarious future when you have copious amounts of free time ;) |
202 |
> |
203 |
> The problem with the current GuideXML system is that anything like this |
204 |
> would have to be coded from scratch most likely. With a standard, popular |
205 |
> CMS, you'd basically get many of these features for free simply by |
206 |
> installing a pre-written plugin or enabling the right option. |
207 |
|
208 |
This new CMS also costs us in terms of infra time to setup, maintain, |
209 |
patch, and generally debug + any hosting hardware we need because it |
210 |
is a complex solution compared to our current one. Arguably the |
211 |
foundation can afford to pay for the latter. |
212 |
|
213 |
The nice thing about the current system is that it is really dead |
214 |
simple, replicates well, serves static content, survives |
215 |
slashdottings, and generally never breaks, dies, and has no weird |
216 |
bugs. |
217 |
|
218 |
So where will we spend this staff? Modifying and deploying an |
219 |
existing solution (think planet.gentoo.org, or bugs.gentoo.org) or |
220 |
modifying our home-grown solution? In the past we have done both. |
221 |
Modifying the XSL is certainly a bit different than your typically CMS |
222 |
but I think an hour or so reading what we have yields some |
223 |
understanding of how to implement new features. |
224 |
|
225 |
Recall that Beandog faithfully maintains planet; Robbat faithfully |
226 |
maintains p.g.o/o.g.o/b.g.o and pretty much most other services; I am |
227 |
unsure if we have anyone willing to maintain a new CMS[1]. |
228 |
|
229 |
[1] Alternatively; nothing really stops you from hosting your own and |
230 |
making mock ups; or adding your own content. Write a GMN and |
231 |
distribute it; convince everyone that this CMS is dead sexy and we |
232 |
should totally run it now. I happen to think most people don't care |
233 |
as much as they say they do because if they did they would do what I |
234 |
hope you do and *do something about it*. But most people complain and |
235 |
do nothing; and I'm perfectly happy to ignore those people ;) |
236 |
|
237 |
>> |
238 |
>>> |
239 |
>>> AllenJB |
240 |
>>> |
241 |
>>> PS. This did start out as a submission for a council meeting agenda item, |
242 |
>>> but I couldn't stop writing. |
243 |
>>> |
244 |
>>> PPS. To preempt the obvious suggestion: I do intend to become a |
245 |
>>> developer, I |
246 |
>>> just don't feel I have the time to commit right now. That'll hopefully |
247 |
>>> change in ~6 months once I've finished uni and have a job. |
248 |
>>> |
249 |
>>> |
250 |
>> |
251 |
> |
252 |
> |