jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Wolfe" <mark.wo...@hsd.com.au>
Subject RE: [PROPOSAL] Management of Taglib Submission process
Date Wed, 08 Aug 2001 03:47:22 GMT
I think that this is an excelent post.

I would love to offer a few hours of my time to this project but find it
hard to really do so when the few suggestions I have submitted are buried in
cvs messages....

Also not all of us have a taglib to submit, but we do have time and
experience we would love to add to this project..

Maybe a little more management is needed to achieve a level organisation
that could handle more taglibs and developers within this project.

Regards,

Mark Wolfe

-----Original Message-----
From: bayard@generationjava.com [mailto:bayard@generationjava.com]
Sent: Wednesday, 8 August 2001 1:28 PM
To: taglibs-dev@jakarta.apache.org
Subject: [PROPOSAL] Management of Taglib Submission process


// 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.



Mime
View raw message