Re: Publicity team review workflow / Re: DebConf11 ends as another success for the Debian Project
On Aug 7, 2011, at 20:36, Filipus Klutiero wrote:
> Hi Jeremiah,
> On 2011-08-05 06:21, Jeremiah Foster wrote:
>> On Aug 3, 2011, at 19:48, Filipus Klutiero wrote:
>>> Should we change the workflow so that adding an announcement has to be accompanied by a mail to debian-publicity?
>> No. The workflow is transparent, consensus based, and flexible. It largely mirrors the way Debian works and has gone through a number of iterations and is currently producing a fairly high quality stream of press releases, weekly newsletters and updates, especially for a volunteer organization.
> Is the current workflow documented?
> I don't see why a new workflow would have to be less transparent, consensus based, and even less flexible (except in the sense that it would be heavier, indeed). Nor why it would not mirror the way Debian works as much.
Heavier is bad.
>> There is no obvious reason a reasonable person could point to that requires changing the current workflow.
> I guess the review workflow's objective is to improve the quality of Debian's communications. How much the increase should be is hard to say.
> The current workflow may give communications a fair "volunteer" quality. But I think we have resources that would enable us to do better than a "volunteer" quality if they are used optimally.
> I imagine the level of quality we should aim for depends on the communication. Communications at a small conference may not need too much review.
> However, in my opinion content sent on debian-news on behalf of the project should have a minimum quality. Would it make sense to offer reviewing guidelines for content sent on behalf of the project? I'm thinking of a "soft approval", an approval granted passively when a content was (appropriately) sent for review to the publicity team and there is no feedback for a certain time, for example 2 days. This wouldn't be a policy, but a rule of thumb indicating that an author truely writes on behalf of the Project. The author who followed this guideline can say a reasonable effort was made to make sure the content actually represents the project.
You've already added a two day delay on things that sometimes are urgent or need to be "fresh". This complicates things without any additional "quality". I don't think it is worth doing this.
> I'm not a communications person, but I suppose other organizations have similar policies.
Either enumerate and suggest best practices from these organizations or perhaps understand that they are often not a true volunteer organization like Debian. Having a formal communications policy is such a heavy weight process and out of scope for Debian. Debian doesn't have the resources for the endless debate that process entails.