[haiku-web] Re: website sub domains was (Re: Drupal Twitter Module)
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Mon, 6 Apr 2009 17:15:17 +0200
Hi gang,
Even though I'm on my way out, I would still like to offer an opinion.
2009/4/5 Matt Madia <mattmadia@xxxxxxxxx>:
> On Fri, Apr 3, 2009 at 5:07 AM, Jorge G. Mare <koki@xxxxxxxxxxxxx> wrote:
>>
>> Sikosis wrote:
>>> So, I guess this brings up a question ... I guess it's been discussed
>>> before ... why are we on version 5 of drupal when 6 is the latest ?
>>>
>>
>> Because upgrades are not easy in Drupal, particularly given the number
>> of modules that our website relies on.
>>
>> (The more our website grows, the more I think it would be a good idea to
>> split it into smaller pieces. It would be so much easier to maintain and
>> upgrade.)
>
>
> Here's my thoughts on one possible way to divide the website into sub domains.
> (assuming that doing so is generally agreed upon)
> Keep in mind, i'm not well versed in website technologies, so it's
> very possible that some of these divisions don't make sense.
> As you can see, I aimed to organize domains by the type of content
> being presented to the user and not by the technologies used to
> implement it.
>
> First, a list of the functionality provided by
> www.haiku-os.org
> news / blogs
> documentation
> forums
> mailing lists
> downloads
> media : screenshots, photos, movies,
> upcoming events
I would always like to remind everyone that when the main website was
designed, it was supposed to become the portal for the current Haiku
community, and as one for new developers that were interested in Haiku
Development.
I must say that this concept worked reasonably well, but of course
over time the communication mix changed, and a new target audience,
the end users, were added.
Now in my opinion, the new structure of the website should primarily
be structured around the three target audiences:
A. Core Developers
B. Community (people involved)
C. Other interested parties (outsiders looking for information, or who
want to give Haiku a test run).
The secondary design criterium should based on specific tools.
Now the core developers (A) are a special case. Their main mode of
communication is through the haiku-development mailing list and
through the source repository. They do not need any special
representation on the web, though one of the challenges is to try to
get them to interact with the community (B) a bit more. They have two
tools: dev.haiku-os.org and repos.haiku-os.org.
The Community (B) are the people that would like to stay informed
about what is happening. They would like to keep in touch with the
development, each other. They would like to contribute by testing (and
writing bug reports), sharing their experiences in installing Haiku,
contributing to the docs, visiting events. Their media are the website
(blogs, news messages), the haiku mailing list, the forums and IRC.
Their tools are the userguide and the developer guide, and sometimes
the bug tracker.
The rest (C) is the most difficult category. We have two important
tasks to help them out. First we need to present relevant information
about Haiku and about trying Haiku in an attractive package. The PR
way. The second task is to make sure that they have just enough
information (and not to little or too much) so that they will not
burden the community with useless questions.
Now these three groups translate to _two_ core websites:
http://www.haiku-os.org for the C. I prefer to have the www as the
first entry point (and not start) because people are likely to have a
look at this anyway.
http://people.haiku-os.org for B (and A). This would be a slimmed
down, restyled, reconfigured version of what we have now as a main
website. This site will host news, events, forums and community blogs.
I chose to call it people instead of community because I personally
think we should embrace individualism, which in my opinion breeds more
personal responsibility than a community, where everybody shares
responsibility which in the end means that no one is responsible for
anything.
Haiku will also host a few tools. These tools are secondary websites
in the sense that they are specialized destinations. This means that I
would not have a separate events site.
The tools are:
http://dev.haiku-os.org
* The well known issue tracker. This can be used to coordinate future
major projects between core developers (this is now meant to be done
in the largely unused team pages on the main website).
http://userguide.haiku-os.org
* The userguide which can be edited by everybody with a
people.haiku-os.org profile. A dump is bundled with every release, the
goal of the website is to rewrite and update the docs for newer
releases, and as an online reference.
This leaves two elements untouched.
1. The mailing lists. I think we should keep these at freelists due to
that we don't have to maintain it anyway. Maybe find a way to
aggregrate them to the people site. Note that it is possible within
drupal to blog about aggregrated content, so if you find someone
willing to go over the lists, he/she can mark interesting posts.
2. The developer documentation. Difficult. Eventually this should end
up on its own website (with the Haiku book and the developer docs),
however, until someone actually steps up to maintain it, having it on
a separate site is useless. You might as well refer to the BeBook and
Be Newsletters from one of the pages on people.haiku-os.org.
I think with this structure you create a framework for future developments.
Kind regards,
Niels
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
Other related posts:
