On Tue, Jan 27, 2009 at 12:17 AM, AllenJB <gentoo-li...@allenjb.me.uk> wrote: > Alec Warner wrote: >> >> On Mon, Jan 26, 2009 at 1:30 PM, AllenJB <gentoo-li...@allenjb.me.uk> >> wrote: >>> >>> Hi all, >>> >>> The Gentoo PR Project currently appears to be having difficulties with >>> keeping up, both with the newsletters and announcements, and I believe >>> this >>> is currently reflecting badly on the project as a whole. These issues are >>> apparently holding back some key changes to the Gentoo website to make it >>> easier to navigate and help the project appear more active than is >>> reflected >>> by the current front page. >>> >>> If the project needs more hands, and these aren't appearing, then perhaps >>> more should be done to advertise the positions and exactly what they >>> entail >>> (I would suggest announcements on the forums, with specifics on who to >>> talk >>> to for those interested). >>> >>> The newsletter has been having issues for some time, and this makes me >>> wonder if the amount of effort required is excessive for the value >>> obtained >>> from those efforts. While the GuideXML system Gentoo uses for >>> newsletters, >>> etc is nice, does it require too much time and effort to convert articles >>> to >>> GuideXML and get the newsletters published? >> >> So you go on to describe issues with thew Newsletter. >> >> What kind of issues? >> Is there not enough content? > > At the moment the newsletter isn't getting published at all. If this is > because there's not enough content being submitted, then I think more needs > to be done to encourage submissions and/or actively seek out and write > articles. > > This comes back to the number of editors the newsletter currently has, which > is influenced by the skills required to work on the newsletter (currently > CVS, GuideXML and knowledge of the scripts used to generate standard > content). >
So in short, we have no idea why the newsletter has not been published. Lets ask the GMN folks (added to the CC) as I am curious as well. >> Is GuideXML in fact a barrier for submission (do we get complaints about >> it?) > > If there isn't enough content being submitted to actually produce one, then > tell the community this. As said above, perhaps mroe needs to be done to > actively seek out and create content. > sounds good; I agree we need to be more vocal here. >> Are there insufficient translators? > > I can't see that translators is an issue, because even the English version > isn't getting published. > >> Are the editors not posting content quick enough? >> Are the editors editing properly? >> Are there enough posters in general? >> >>> Alternative setups for the newsletter could be to either go text-only or >>> web-only. >>> >>> Text-only would involved producing a text-only email, which is then >>> copied >>> and pasted onto the website for archiving. This would obviously require >>> minimal formatting work. >> >> Ok, but if the problems are with finding material; changing how the >> material is posted will not help. > > The idea behind this was to reproduce the amount of work involved in taking > a plain text submission (which I would guess is the form most submissions > come in) and getting it published in the newsletter. This method removes the > need for conversion to GuideXML. Hrm, I assume s/reproduce/reduce/ here. I personally think transcribing the text to guideXML is a fairly simple process and y'all are a bunch of whiners (and I am too; work has HTML documentation and it sucks). But its what we have and it works fairly well and I think a lot of folks are annoyed when people pop in to redesign everything. We resist change ;) > >> >>> My idea for a web-only setup would require more initial work, but I think >>> would make maintenance much easier once set up. The Gentoo Newsletter >>> would >>> become a separate website, not based on GuideXML, but on a standard CMS. >>> Instead of having set release dates (weekly or monthly), articles would >>> just >>> be released as soon as they are produced. >> >> Why does a new shiny CMS enable this? Certainly we could provide >> access to news/ to a broader audience? >> You seem to think the target audience cannot author GuideXML though. >> >>> The regular features like bug stats, GLSAs, developer changes could be >>> easily generated automatically (I suspect almost all of those are mostly >>> done automatically anyway - adapting such scripts for a CMS that can >>> publish >>> from RSS feeds should be relatively trivial) and would appear on the >>> website >>> without any intervention. >> >> This is covered by index2; so I'll ignore it ;) > > You're assuming index2 ever goes live. From what I've seen it's been hanging > around for at least 6 months in a "ready to go live" state, so I'm not > holding any hopes of this happening any time soon. =P Getting Index2 live is I think a different operational issue (that changes to the website are very slow) and really has nothing to do with PR aside from them not nagging someone to commit it ;) >> >>> As above, articles would be published as and when they are ready. Instead >>> of >>> just 1 editor, this website-based setup would be able to have multiple >>> editors with little collaboration required (just to mark submissions as >>> being worked on when an editor picks them up, which should be easily >>> doable >>> using a ticket-based system (bugzilla) or mailing list). >> >> Does the current news have only 1 editor? I am on PR but I tend not >> to commit news or approve things. > > Why do you not tend to commit news or approve things? PR@ is a nghtmare of spam and what I'll term 'crap.' having real things marked as such with informative subjects would be useful. having some kind of rotation would be useful having some kind of vague 'we will read and respond within 3 days unless its a holiday' would be useful. Right now the expectations of pr@ are non-existent and apparently think the mail is read and answered quickly. In reality only Donnie reads it and replies; he has a busy as hell personal life and I'm surprised he manages to read it at all. So I would like to set expectations ;) > > It may not be just the 1 editor, but I suspect the problem is a general lack > of active editors. From what I've read, current GMN publishers require > knowledge of how to run all the scripts to generate the standard content and > write GuideXML to a pretty good standard. I suspect this is all quite time > consuming (from the little I've done in GuideXML, I certainly find that time > consuming). > > This suggestion would: > 1) Drop the skill requirements for news article publishers to being able to > operate a CMS > So if I promised news to be published within 3 days; would that cut it for you? > 2) Require minimum collaboration between multiple editors, allowing the > number of editors to be easily increased. Inactivity shouldn't be an issue > in this system, because no single editor is responsible for collecting > everything together and publishing. Arguably no single editor should be responsible in the current system either. There 10 people (excluding infra) who have access to commit to main/ Obviously we have the wrong 10 since 9 of them (including me) don't seem to be doing much ;) > >> >> I would propose an alternative alias or subject tag that will single >> your post request out from the other trash that gets sent to pr@; that >> way it might actually receive some attention. >> >>> An advantage, as I see it, of the website-based system is that it could >>> be >>> expanded to include features not currently easily possible with the >>> current >>> newsletter - categorized archiving of articles (not just be publish date) >>> and user comments. While I haven't looked, it's probably possible to even >>> find a CMS which includes email notification of new articles as a >>> feature. >> >> This is a bad sell; we could certainly expand the current one as well >> (with cool new features!) except we have no staff for that (in either >> system). Talk about what you will do; not what you plan to do in the >> nefarious future when you have copious amounts of free time ;) > > The problem with the current GuideXML system is that anything like this > would have to be coded from scratch most likely. With a standard, popular > CMS, you'd basically get many of these features for free simply by > installing a pre-written plugin or enabling the right option. This new CMS also costs us in terms of infra time to setup, maintain, patch, and generally debug + any hosting hardware we need because it is a complex solution compared to our current one. Arguably the foundation can afford to pay for the latter. The nice thing about the current system is that it is really dead simple, replicates well, serves static content, survives slashdottings, and generally never breaks, dies, and has no weird bugs. So where will we spend this staff? Modifying and deploying an existing solution (think planet.gentoo.org, or bugs.gentoo.org) or modifying our home-grown solution? In the past we have done both. Modifying the XSL is certainly a bit different than your typically CMS but I think an hour or so reading what we have yields some understanding of how to implement new features. Recall that Beandog faithfully maintains planet; Robbat faithfully maintains p.g.o/o.g.o/b.g.o and pretty much most other services; I am unsure if we have anyone willing to maintain a new CMS[1]. [1] Alternatively; nothing really stops you from hosting your own and making mock ups; or adding your own content. Write a GMN and distribute it; convince everyone that this CMS is dead sexy and we should totally run it now. I happen to think most people don't care as much as they say they do because if they did they would do what I hope you do and *do something about it*. But most people complain and do nothing; and I'm perfectly happy to ignore those people ;) >> >>> >>> AllenJB >>> >>> PS. This did start out as a submission for a council meeting agenda item, >>> but I couldn't stop writing. >>> >>> PPS. To preempt the obvious suggestion: I do intend to become a >>> developer, I >>> just don't feel I have the time to commit right now. That'll hopefully >>> change in ~6 months once I've finished uni and have a job. >>> >>> >> > >
