[webteam] welcome

Sander Devrieze s.devrieze at pandora.be
Tue Jul 10 02:49:12 CDT 2007


2007/7/10, Hal Rottenberg <hal at halr9000.com>:
> > So, again, this is how I would like the jabber.org project to be:
> > * workgroups/teams
>
> Drupal has ways to separate logical groups of a site into separate
> more autonomous pieces each with their own theme, etc.  Think
> slashdot.org vs. games.slashdot.org (altho the theme difference there
> is minimal).  I forget if they call it 'sites' or 'sections' but I
> think you see what I mean.  Why don't we take the different focii and
> give each one its distinct section.  Then we break off into smaller
> groups (or not), but the point here being that we won't confuse
> different audiences.  Once we get further into the site mechanics we
> can work on how to make the various sections visually distinct.
>
> According to the wiki page, the focii are at present:
>
>     *  End Users (main focus)

Not needed, we just have to give client projects the tools to target
end users. E.g. we can create some copyleft introduction to Jabber
that client projects can put on their website.

>     * Managers

Not needed, we just have to give client projects the tools to target
managers. E.g. a database of case studies they are allowed to put on
their website.

>     * Server Admins

Not needed, we just have to give server projects the tools to target
admins. E.g. we can give server projects that lack a good community
website the knowledge to set up a good community website (I thinking
about jabberd14 and jabberd2 of course).

>     * Developers

Not needed, library projects have to target these people. We just have
to sustain them.

-->IMO we only should target the community of contributors to Jabber
projects with this website. We already have a protocol based community
which is a scarce and very valuable key advantage of Jabber. So, it
would be good to stay focussed on this and make this community
stronger.

So, I was more thinking about flexible and organic teams. So, having a
fixed subdomain is a restriction for teams to die when they are no
successful. Also, I was more thinking about flexible and temporary
teams like:

* "Help Launchpad to integrate Jabber team"-->will die when we
accomplished this goal
* "Create a Jabber software timeline team" (I started with
this)-->will die when the timeline is ready, only updates are still
needed afterwards
* "Help Jabber client projects to create video tutorials team" <--will
die when all client projects have the knowledge to maintain this
themselves
* "Create a list of Jabber vocabulary for translators" <--will die
when that list is finished
* <put your project here>

-- 
Mvg, Sander Devrieze.


More information about the webteam mailing list