// In response to a suggestion for a formal proposal from Pierre.
// Apologies if I unwittingly mis-represent the way things are.
// Please pick holes/issues with these ideas.
// Bay
Proposal for management of taglib submission process
====================================================
This proposal is intended to improve the process for
submitting taglibs. The major tools that may be used
are the Jakarta Taglib webpage and the taglib-dev and
taglib-users mail lists. The obvious roles are
submitters, committers, developers and users.
Currently there are a few noticable problems with the
submission of taglibs to Jakarta. These are:
i) Lack of feedback keeping submitters in the loop.
ii) Lack of management of pre-jakarta taglib taglibs.
iii) Hard for committers to get a feel as to which
submitted taglibs are more desired by developers.
iv) Submitted taglibs tire and head off to sourceforge to
setup their own project there.
v) No way for users to know about 'in the works' taglibs.
Taking each of these problems at a time, explaining,
and proposing solutions;
i) "Lack of feedback keeping submitters in the loop."
A submitter sends a Proposal to the taglib-dev mailing list.
Developers may send a recognition of that proposal, very
occasionally a proposal will not get recognised. This is
the first feedback problem, unstructured recognition of
proposals.
As time goes by, the submitted taglib may be viewed by a
committer. Usually the triage used to decide which taglib
to view is based purely on that committer's interest in that
taglib.
While interest continues, it slowly moves towards a successful
submission.
=solutions=
* Have someone who can provide an immediate official recognition
that the submitted taglib is now classed as submitted.
* Allow developers to review in a structured way. Provide a
very simple process to rate a taglib. Other details can follow,
but this would allow developers to vote on a status.
* Improve spec for a jakarta taglib so that a submitter has
something to work to. Have the submitter provide documentation
in a standard format.
* improve voting to allow triage of submitted taglibs.
ii) "Lack of management of pre-jakarta taglib taglibs."
After a while, it becomes apparant that submitted taglibs
easily get forgotten about. The only persistent record is
the mail-archive, a data-store that contains lots of
other information.
If a submitted taglib gets a new version, or a list of bugs
is created, how is this passed on to the interested parties.
=solutions=
* Website details submitted taglibs. In fact submission could
happen through here, but would require more effort.
* Email weekly/monthly about latest state of submitted taglibs.
This email could detail the apparant interest in the taglibs,
what state they're in in the submission process, where the
hold up is, and who is the current reviewer. If a taglib
is starting to slip through the cracks, this email could
request if there is still demand and try to find more
reviewers.
* Awareness as to who is managing which pre-taglib.
This suggests a general manager for pre-taglibs who then hands
off to committers. Once a committer is dealing with a submission
it's up to them as to whether to use developers as reviewers
or to just review it themselves.
iii) "Hard for committers to get a feel as to which
submitted taglibs are more desired by developers."
A committer needs to have a feel for the demand for a taglib.
A dynamic graph taglib may be fervently desired by a small set of
developers, whilst a javascript taglib may be desired by a larger
set, but not as fervently. Committers need to know this
and balance the demand.
The current method is based on how vociferous a reply a
submitted taglib gets.
=solutions=
* Voting on the website to indicate which is desired.
* Voting via email.
* Request for demand emails. This seems the most likely solution,
at specified points in a submission's lifetime, votes would be
made on the demand. This matches the current process for
taking action on existing taglibs.
iv) "Submitted taglibs tire and head off to sourceforge to
setup their own project there."
When a taglib spends a while moulding in the process, the taglib
author is likely to head off to sourceforge or somewhere else and
set it up as a separate project. While this is in no way a bad thing,
it is a lost opportunity to the jakarta-taglib project. If the
separate taglib is successful it will detract from the aim of
the taglibs project of encompassing the open source taglibs. If the
separate taglib is unsuccessful, it could be because it was unable
to find the user-audience it could have found on the jakarta-taglib
project. Both the submitter and the few, yet fervently desiring,
users lose out.
=solutions=
* More feedback should stop this happening. A flow of communication
between the submitter and the jakarta-taglib person currently
responsible for the submission should stop taglibs wandering away.
* Short term, get feedback to as many submitters as possible.
An early solution should be to review the current submissions,
and initiate/repeat feedback to all submitters.
v) "No way for users to know about 'in the works' taglibs."
There may be a user sitting on the taglib-users mail list, or
browsing the site, who is desparate to use a NetREXX parsing taglib.
Chances of them finding it on some obscure out of the way personal
page is low. Chances of them finding the single entry in the
taglib-dev mail list in which someone from IBM offered this is
also low.
=solutions=
* Currently submitted taglibs can be listed on the website.
This is the equivalent of some form of early access program.
* Taglib-users gets monthly emails on currently submitted taglibs.
Possibly in balance with a monthly email discussing the latest
changes to the jakarta-taglib that affect users. I don't know
if this is done already.
* Taglibs that aren't successful can still be linked to from the
taglib page. Just because a taglib wasn't successful in being
submitted, that doesn't stop jakarta-taglib from providing
information and a link to it.
==========
To conclude, I suggest that the major solutions to implement are
an increase in feedback to submitters through weekly/monthly
emails, through awareness of where in the process of submission
a taglib is and through awareness of who is currently responsible
for a submission.
