Hi,
> This is a call for help with redesigning the Midgard Web site
> to the level required by our project. We need to make information
> on Midgard more easily available, and help new users to get
> involved with the Midgard community and development work.
IMO: Bad information detracts from good information. We need to delete
everything that's dated. We've got Marius' rewrite of Azman's installation
from source. Why is Azman's original article still on the site? Probably
because there hasn't been time to move the document into an archive, if such
an archive is even needed, I'm doubtful.
The graphic tour needs to be redone with Asgard
graphics, perhaps even rethink it's content. It's almost a decent little
tutorial.
I think we need to do an inventory of the site and list everything that's
no longer relevant.
> We need people who can volunteer some time to work on a aspect
> of the new site. Available tasks include:
> * Graphic design
> * Authoring of marketing material
> * Programming applications for the site
> * Maintaining material on the site
>
> Services:
>
> * Bug Tracker / Wishlist
> * Mailing list archive + mailing frontend
> * Nightly builds repository with commenting options
> * MPRy member management
> * Announcement publishing
> * MWS publishing
> * Release management, both betas and stable releases
> * Who's who, a listing of project participants and their tasks
A list isn't a good solution, nobody is going to read a list and the
people that are doing the work aren't going to recieve their due credit.
View the following page and click on the colored things, replace the build
information with reports on snippets, features, who is writing them, state
of development, anticipated completion dates, etc.
http://community.roxen.com/developers/autobuild/pike71.html
> * Documentation and annotations
Sorry, going to repeat myself. Henri is just returning and probably hasn't
had time to read through the mail archives.
I think we should consider Commentext as the solution for documentation.
In my opinion, there are barriers which prevent participation and
contributions; cvs, sgml, etc. Time and energy to write documentation
are a serious problem.
Commentext performs document versioning in a bulletin board type
environment--annotations on steriods. Paul Newby has stated that he'll
announce the Commentext license when Repligard is fully functional, I
imagine we'll here something soon. In my opinion, Commentext is suited to
dealing with all the problems that I've mentioned and then some. Anything
that is official Midgard documentation should be put into Commentext.
The Midgard 1.4 manual belongs in Commentext where users and developers can
submit edits and additions. A non-MPRy decision was made, during a meeting
with developers employed by Aurora, to not allow anyone to edit another
person's documents. IMO, this goes exactly opposite of MPRy's interests,
the spirit of Open Source, and the needs of our community.
The annotations program, roughly modeled on the php documentation
strategy, has shown its usefulness. Commentext is a feature rich
environment that can completely change how we generate and manage the
documentation.
> * Midgard-powered sites listing
> * Snippet repository
>
> The site should also have an integrated Midgard-based administration
> interface for all these features.
In general: the site should be thought of as a tool, not a site. In it's
current state, we always see the same information, nothing changes but
many things are undergoing updates within the effort. I'd suggest studying
publishers like The New York Times, Salon, Fresh Meat, slashdot,
Roxen, blah blah.
> Platform:
>
> The work will be done on an Envida server running Midgard 1.4, and
> will be done using new features provided by the Bifrost release.
> This means that we will write all applications in a Repligard-
> friendly way, and will use CodeSnippets for code management.
>
> If we have enough resources, the site will also be localized
> to some languages using a mechanism similar to the one used
> in Asgard. If so, we will also need translation help.
I don't imagine it's feasible to use Repligard in a qausi CVS
strategy, allowing many people to work locally, commit updates, update
local instance.
> Replication issues:
>
> Everything will have to be done with Replication in mind.
> We currently have several mirror sites available, and those
> will be handled by Repligard in the future. Because the
> mirror providers can provide varying levels of service,
> we will also have to have different mirrorable site versions
> available:
> * Full Midgard site handled by Repligard
What happens if we decide to run some applications from the filesystem?
Will we be able to?
> * Site converted to static HTML
> * Midgard download packages only
>
> We will also need to provide simple instructions for mirror
> providers, and a way for them to register their mirrors.
Speaking of instructions, how about instructions for the people that are
going to maintain the site one or two years from now? I hope the new
site will be friendly and flexible.
> How to contribute:
>
> The work will start on Jan 8th. Please let me know if you
> want to help with some aspect.
If enough of us are on the same page with the need to prune dated
content and replace it with current material or simply remove it, I'll
inventory the site and write a report.
Ron
> /Bergie
>
> --
> -- Henri Bergius -- +358 40 525 1334 -- [EMAIL PROTECTED] --
> http://www.iki.fi/Henri.Bergius
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
