[Members] communications team
stpeter at stpeter.im
Tue Oct 20 16:10:37 CDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 10/20/09 4:50 AM, Nicolas Vérité wrote:
> On Tue, Oct 20, 2009 at 00:49, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Here's another informal team definition, this time for the
> communications team.
> This team works on various written materials published by the XSF. I
> think the tasks in scope for this team include:
> 1. The xmpp.org website -- content, look and feel, etc.
> 2. blog.xmpp.org (might get folded into the main website)
> 3. wiki.xmpp.org (probably not a high priority)
>> I would personnaly set it a higher priority. BTW, I've cleaned up some
>> pages, and I'll contribute more. We can take examples on the Spanish,
>> French and Czech communities.
I don't think those items were in preference order. However I think that
the job of the communications team is more to prune the wiki than to
create a lot of content there. I see the wiki as a good workspace and
not such a good permanent repository of information.
> 4. Whitepapers (no we don't have any yet -- need to fix that)
>> Isn't this format a little bit old scool? Or at least reserved to a
>> certain population? I think we would more efficient by making
>> enthusiasts (micro)blog about what they like in XMPP.
I get requests for whitepapers all the time. They hold a lot of weight
with decision-makers in corporations and government. Different styles
for different folks. :)
> 5. Conference materials / brochures
>> We have this:
>> Please, fellow members, add your talks there.
I meant things like brochures. Presentations are good, too, though. We
can borrow the stuff that's been posted at SlideShare as well.
> 6. Editorial issues related to XEPs (proofreading, copy editing)
>> BTW what about homogenizing things like the length, style and language
>> level in non-technical parts of XEPs, like the abstracts, intro,
>> requirements, etc.?
I don't know if those things need to be homogenous, but more consistency
would be good. I've tried to keep things mostly consistent, but our
specifications have been produced over a period of 8+ years so we have
learned quite a bit over time. For instance I think it would be good for
each XEP to have a friendly "how it works" section at the beginning. The
same might be true of introduction, motivation, requirements, and so on.
Another area of focus might be more developer-friendly documentation,
because it's just wrong to throw big specs at your average application
developer. We tried that here but didn't get far:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Members