jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: [PROPOSAL] Management of Taglib Submission process
Date Wed, 08 Aug 2001 03:39:34 GMT
Documentation on how to create a taglib which complies to the
jakarta-taglibs standards is already covered by:


Perhaps create another document called Contribute Taglib with details
on how to submit a taglib to jakarta-taglibs.

We should consider using bugzilla to manage submission of new
taglibs.  We can create a new category called Submit New Taglib
and assign that category to the committer currently responsible.

Bugzilla allows assigning someone else to a "bug".
Bugzilla has a voting system.
Bugzilla has a way to capture any communications regarding the
submission, etc.

We could put a link to bugzilla with a get query string which
automatically brings up active submitted taglibs on the main
jakarta-taglibs web site page.

I think Bugzilla could work well for tracking new taglib submissions,
provided we write up some documentation submitters can follow to
accomplish the task.



bayard@generationjava.com wrote:
> // 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.

Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

View raw message