>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 1/3/01, 6:48:10 PM, Henri Bergius <[EMAIL PROTECTED]> wrote
regarding [midgard-user] Midgard Web site redesign:
> 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.
> through the site. All these should be native Midgard applications
> programmed following the CodeSnippet coding standards:
Strongly agreeing, I'd like to know what exactly is the Codesnippet
standard:
The code snippet feature was implemented so that chunks of code could be
easily shared. Some could be pluggable applications, others could be more
like libraries. With a sufficient codebase available a user could then
simply download and install the desired sitelogic and have a functional
site in no time. By providing a sharing mechanism we would then enable
the application level developers, who could then contribute their work
and experience into the snippet pool. Decreasing the learning curve for
new users, attracting new application level developers... in other words,
code snippets are here to bring an increasing upward spiral to the
Midgard Project.
But... code snippets have been around for some time, and the candy above
has not yet happened. Why?
1) Snippets are prone to namespace problems.
2) A sharing mechanism was not available.
Breakdown:
1 - Snippets are related to a path, and they often
need to know that path to be able to find other snippets
they depend upon. If I create a snippet named
/foo/sociallife/midhoo wich does the laundry and the
dishes, then Henri might be intrested in it. He has a
snippet that wakes you up with your favorite song, makes
coffee and your bed. It happens to be named /foo/sociallife/midhoo
OOPS! Because of the naming we can not exchange snippets
without going through the tedious task of editing the snippet
to look in a different path.
TODO: A - define a naming convention that avoids these
nameclashes.
2 - Repligard has seen the light, and is functional. Further
improvements are underway for midgard 1.4.1
TODO: B - define and document the right and proper way to
export your snippets,
C - define and document the right and proper way to
import other peoples snippets.
Opinion:
item A must be resolved before development of any of the desired
applications can start, B and C should be done in time with the release
of 1.4.1
> * Bug Tracker / Wishlist
> * Mailing list archive + mailing frontend
> * Nightly builds repository with commenting options
And reporting too. Testing of nightlybuilds is currently done by hand,
and thus prone to error. I want to extend the build process with a
testing cycle, and present the results together with the downloadables. I
would like some help here, as my brain is stuck on thinking up the right
approach for some time now.
> * 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
Add open tasks, things we want to do, but have no resources for yet.
> * Documentation and annotations
> * Midgard-powered sites listing
> * Snippet repository
> The site should also have an integrated Midgard-based administration
> interface for all these features.
> Platform:
> The work will be done on an Envida server running Midgard 1.4,
Oh? ;-) Okay, I'll set up a host in the same sitegroup as nightlybuilds
currently sits, and make you a sitegroup admin.
> 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 think we should build localized regardless of the available resources.
If sources lack there will only be one locale available. This way we
don't create an impossible task if resources do come available at some
point in time.
> 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.
Design issue:
Documentation on the site is currently generated html from sgml sources
in cvs, pulled in to the site. Coming up with a solution that is
repligardable is a challenge. It requires rethinking our current
documentation methods. Not necessarily a bad thing. Commenttext springs
to mind.
> 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
> * 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.
> How to contribute:
> The work will start on Jan 8th. Please let me know if you
> want to help with some aspect.
Armand.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
