[Helma-user] Proposal for future Helma project organization

[Hannes Wallnoefer]

Thanks for all the (mostly positive) feedback so far.

2006/10/19, Michael Platzer <michael.platzer at knallgrau.at>:
> Robert Gaggl schrieb:
> > First i'd like to state that i really appreciate hannes' proposal, as
> > it's a first important step towards a clearer structure of the helma
> > project itself and the further development. So i'm all +1 for it.
> >
> great. i would suggest that we set a target date for the 'bootstrapping
> phase' if no dissenting votes are raised (speak up now, or remain silent
> forever :-) ), in order to get things moving.

The bootstrapping phase will start by compiling a list of probable
modules, and think about who would be willing and able to maintain
them. In that sense, the starting signal will be to scribble down the
list I currently carry in my head on
<http://dev.helma.org/Wiki/Helma+Modules/>. For a date when the
bootstrapping phase should be finished, I don't feel confident enough
to tell right now. Maybe we'll get a feeling for that once  the
process is underway.

> > I think it will need careful consideration which parts will be a
> > "module" in the sense of a separately maintained subproject. For the
> > development part of helma at the beginning i can imagine only two of
> > them: helma core and  javascript-lib(s). Both modules will possibly be
> > divided into different modules in the future [1]. But the development is
> > just one part in the project, besides documentation/training, release
> > management and communication/presentation (including website
> > maintenance), which i personally consider of equal importance.
> >
> me too. and that's why i would also define them as being a 'module'.
> otherwise we start out with helma committee of two people, which feels
> kind of lame.

Yes, it is also my intention to establish modules which are not
centered around coding.

> or we rethink the requirement of a member to be a module-maintainer, and
> decouple these two things.
> plone's membership guidelines for example feel less formal, but are
> probably still effective, since it is based on trust and personal
> judgement instead of predefined rules:
> http://plone.org/foundation/membership/meritguidelines/ (i know that
> being a module-maintainer does not automatically mean being a committee
> member)

I really like those plone guidelines. I hadn't come across them
before. They meet my intentions pretty well of what the requirements
for committee membership should be.

> i think, we should restate the main goals of the bylaws, respectively of
> the new community structure. ergo, what do we expect from such a
> process? in my opinion, the objectives are the following:
> 1) relieve pressure from Hannes, by establishing a structure that does
> not necessarily depend on him as a person.
> 2) a clear definition of responsibilites, in order to know who is
> supposed to do what and when?
> 3) a clear definition of decision processes, in order to make them more
> transparent, fairer and faster.

I think points 2) and 3) about responsibilities and decision process
are already stated in the bylaws in a pretty similar way (we can
improve the wording, of course). Point 1) should be a natural
consequence of implementing the bylaws. We can add something like 1)
if it is abstracted away from my person (e.g. "limit responsibility of
any one person").

> The helmaLib right now is a mixture of some javascript-helpers
> (String.js, Date.js,..) and some java-wrappers (helma.File, helma.Ftp,
> helma.Http,..). For the former, I rather prefer a javascript-library,
> such as prototype.js, which is widely known and also used for
> client-side javascripting. For the latter, I prefer using the
> java-libraries and -classes directly, since their APIs are well
> documentated and well tested, and the pool of available, useful
> libraries [1], [2], [3] is just endless.

I think using (or being able to use) third party JS libs shouldn't
contradict having or building our own libraries. Regarding the use of
Java libs, I disagree: Java APIs are often too low-level, and often
creation/conversion of parameter types or return values is cumbersome.
Building standard wrapper libs is definitely the way to go IMO. In the
end, I think it is desirable to have generic helpers, java wrappers,
_and_ web specific stuff as listed below.

> But the tasks/issues that a web developer daily faces go much much
> further than the helmaLib currently covers. It's about security, form
> validation, model validation, pagination, searching, code testing, code
> documentation, clean mvc separation, ajax integration, upgrade
> mechanism, design patterns, naming conventions, and so on. Building a
> helma framework that goes that far based on a common community
> agreement, which tries to please everybody, just doesnt seem realistic
> too me (considering the lengthy discussions  we have seen here on this
> list from the past).

It is the purpose of Helma 2 to provide a framework that covers
everything a web developers deal with on a daily basis. This will
probably include all or most of the areas you list above. I don't see
why we shouldn't be able to get this done.

hannes