1 |
Hi all, |
2 |
|
3 |
The Gentoo PR Project currently appears to be having difficulties with |
4 |
keeping up, both with the newsletters and announcements, and I believe |
5 |
this is currently reflecting badly on the project as a whole. These |
6 |
issues are apparently holding back some key changes to the Gentoo |
7 |
website to make it easier to navigate and help the project appear more |
8 |
active than is reflected by the current front page. |
9 |
|
10 |
If the project needs more hands, and these aren't appearing, then |
11 |
perhaps more should be done to advertise the positions and exactly what |
12 |
they entail (I would suggest announcements on the forums, with specifics |
13 |
on who to talk to for those interested). |
14 |
|
15 |
The newsletter has been having issues for some time, and this makes me |
16 |
wonder if the amount of effort required is excessive for the value |
17 |
obtained from those efforts. While the GuideXML system Gentoo uses for |
18 |
newsletters, etc is nice, does it require too much time and effort to |
19 |
convert articles to GuideXML and get the newsletters published? |
20 |
|
21 |
Alternative setups for the newsletter could be to either go text-only or |
22 |
web-only. |
23 |
|
24 |
Text-only would involved producing a text-only email, which is then |
25 |
copied and pasted onto the website for archiving. This would obviously |
26 |
require minimal formatting work. |
27 |
|
28 |
My idea for a web-only setup would require more initial work, but I |
29 |
think would make maintenance much easier once set up. The Gentoo |
30 |
Newsletter would become a separate website, not based on GuideXML, but |
31 |
on a standard CMS. Instead of having set release dates (weekly or |
32 |
monthly), articles would just be released as soon as they are produced. |
33 |
|
34 |
The regular features like bug stats, GLSAs, developer changes could be |
35 |
easily generated automatically (I suspect almost all of those are mostly |
36 |
done automatically anyway - adapting such scripts for a CMS that can |
37 |
publish from RSS feeds should be relatively trivial) and would appear on |
38 |
the website without any intervention. |
39 |
|
40 |
As above, articles would be published as and when they are ready. |
41 |
Instead of just 1 editor, this website-based setup would be able to have |
42 |
multiple editors with little collaboration required (just to mark |
43 |
submissions as being worked on when an editor picks them up, which |
44 |
should be easily doable using a ticket-based system (bugzilla) or |
45 |
mailing list). |
46 |
|
47 |
An advantage, as I see it, of the website-based system is that it could |
48 |
be expanded to include features not currently easily possible with the |
49 |
current newsletter - categorized archiving of articles (not just be |
50 |
publish date) and user comments. While I haven't looked, it's probably |
51 |
possible to even find a CMS which includes email notification of new |
52 |
articles as a feature. |
53 |
|
54 |
|
55 |
AllenJB |
56 |
|
57 |
PS. This did start out as a submission for a council meeting agenda |
58 |
item, but I couldn't stop writing. |
59 |
|
60 |
PPS. To preempt the obvious suggestion: I do intend to become a |
61 |
developer, I just don't feel I have the time to commit right now. |
62 |
That'll hopefully change in ~6 months once I've finished uni and have a job. |