[sword-devel] Project management issues with the Sword Project

Troy A. Griffitts scribe at crosswire.org
Fri May 11 16:26:02 MST 2007


Thank you for the great information.

Your offer to help has solicited good feedback from other active members 
and it seems we are all on the same page.  It sounds like the primary 
concern from all who have chimed in is the reorganization of the 
websites (not necessarily the development services).

I'm sorry to hear about your preference for perl and php :)  So as not 
to start a technology flame war here, my feeling is that there are many 
able technologies suitable for the job.  Keeping a standard single 
technology set on the server is crucial for maintenance with a small 
staff and as people come and go (and especially during server upgrades). 
  And as for popularity, our choice is not against any grains 

Practically, our sites don't have much need for dynamic content, and 
where there is a need, we already have a library of tools written in 
Java/JSP to meet those needs (news postings, auto-packaging and display 
of modules, etc.).  I am reluctant to commit to the technology overhead 
of a full cms, and as you have suggested, feel it is overkill for our 
mostly static site.  I hope the small places where Java/JSP is used 
won't turn you off too much to helping, if you are still willing.

I am very excited to see your ideas as a 'wire frame comp' (not sure 
exactly what this means :) ).

My hope is that our technology continues to NOT be static, but that we 
will carefully think through these static pages that direct people to 
our tools.  Good or bad, these pages have remained as they are for a 
number of years, and any changes we make will likely remain the same for 
a number of years to come.


Andrew Sterling Hanenkamp wrote:
> Troy,
> No, you have not discouraged me so much as spawned more ideas. The only 
> discouraging aspect as far as I'm concerned is the choice of platforms. 
> I'll get to that in a bit.
> The proposal of Trac was just a proposal of the kind of tool I think 
> might replace/combine all the others. If you implemented Trac the way I 
> was thinking there would be no more links to Sourceforge, use Trac for 
> issues rather than JIRA, SVN integrated into Trac, Wiki integrated into 
> Trac, etc. I was suggesting this for sword itself, not as service to 
> provide to related projects. It was a suggestion that it seems like too 
> many different tools are being used for the core project itself and Trac 
> is a pretty good all-in-one, with some limitation. For example, 
> customizing Trac can be a royal pain and it doesn't integrate with 
> e-mail very well. Trac is just one tool for the job, there are many 
> others and there's nothing that says the current tools couldn't be 
> pulled together more cohesively. Given your platform list, however, Trac 
> is completely the wrong tool.
> As you described the web site itself, a new layout formed in my mind. I 
> may see if I can come up with a wire frame comp to share that could 
> serve to organize the site more. My original email was really only 
> concerned with the Sword site itself. The top level Crosswire site 
> hadn't really hit my radar yet, but given your concerns, it certainly 
> could stand to be reorganized as part of the process.
> The JSP itself seems to work pretty well as far as it goes, but it's 
> obviously not very flexible. That's no sleight against the original 
> programmers as are any of my observations. I would recommend replacing 
> the current code with a content management system of some sort that 
> would allow the site to be updated and changed without having to touch 
> the files themselves. All the content would then be stored in a database.
> However, given the platforms you prefer (Firebird/Apache/Tomcat), I may 
> not be the best person available for this work. I am very familiar with 
> Java and JSP and JDBC and a lot of other J-words. Much of my recent work 
> over the past year has involved using a Java-based CMS using a JCR 
> database back-end. However, all of my volunteer projects and work are 
> heading towards PHP and Perl and I find that it's better not to divide 
> my attention too widely. I also much prefer MySQL/Apache/FastCGI using 
> Perl (or PHP when I must) and would rather not work on a Java-based 
> platform if I can avoid it.
> I can give some recommendations, though. The closest tools to your 
> current systems that I'm aware of are Magnolia, Alfresco, and Liferay. 
> Alfresco would probably be my top recommendation out of these. Liferay 
> is a great company, but I don't know if a Portal-driven CMS is really 
> the right fit for Crosswire. The enterprise edition of Magnolia works 
> great, but the Open Source version is just sufficient and requires a lot 
> of footwork to really make use of. All of them a very much heavier than 
> your current solution, so they all might be too much for the project 
> anyway.
> The Bible Tool software is something I wasn't previously aware of. It is 
> similar to another tool I'm hoping to build (though my tool would be 
> intended to be more collaborative) using a domain I have purchased for 
> that purpose (and am currently using as one of my blogs). Again, though, 
> I'm not too interested in a Java-based tool, so it's probably not a good 
> fit.
> As for a Java-based wiki, there are now a couple good ones out there. 
> The most notable is called Confluence, which I believe is available for 
> free for Open Source projects. It is, however, a bit on the heavy side. 
> JSPWiki is also a pretty decent one and seems to be lighter. Again, I 
> don't care for Java-based platforms, but I am pretty familiar with them 
> having hosted my work web site on a JCR-based CMS for the past year.
> I'd say that I'm not sure that I'm very excited about the prospect of 
> helping rebuild Crosswire/Sword using Java, but I'm still interested in 
> discussing it further. I could definitely provide some ideas, design, 
> and help managing how the site is organized in any case.
> Also, I don't know if my previous message got through since I forgot to 
> fix the From address, but I am interested in trying work with the SWIG 
> bindings as well. I've thought it over and the more I'm working on them, 
> the more interested I am in trying to make them function better. I have 
> an email in my Drafts I started composing that I'll send through when I 
> finish it.
> Cheers,
> Sterling
> P.S. Is there an IRC channel somewhere?
> On 5/9/07, *Troy A. Griffitts* <scribe at crosswire.org 
> <mailto:scribe at crosswire.org>> wrote:
>     Andrew,
>     Thank you for offering your help regarding our project websites.  I
>     agree with your assessment; a reorganization would be a welcomed
>     change.
>       Here are a few of my specific thoughts on the matter:
>     Most frontend projects have their own website, bugtracker, source
>     repository, etc.  CrossWire makes these services available from our
>     server (apache/tomcat, jira, svn, ...), but most projects still choose
>     to use sourceforge or another site-- which is fine.  I am hesitant for
>     us to install something like Trac, when sourceforge and google are
>     focused on providing such services.
>     The goal of the main CrossWire page is to initially welcome all
>     kinds of
>     users and filter them to the correct sub-site tuned to their interests.
>       Organizing this is a challenge-- end users of Bible software want
>     something very different than developers looking for API examples.
>     The SWORD Project site (http://crosswire.org/sword/) seems more geared
>     to developers and contributers than it does to end user, but this is the
>     only place for end users to find certain information.  For example it
>     has a facility to let project leaders post news items about their
>     project.  This should probably be moved to the CrossWire main page.
>     Module downloads are also under the SWORD site, though there is a link
>     directly from the main CrossWire site.
>     The current site layout was contributed by good-hearted people just
>     learning about JSP includes.  The current page structure makes difficult
>     the task of adding a side menu choice, and the locations are not very
>     modular.  I have no strong feelings which would prevent unwinding the
>     complexity to a simple layout.
>     Our online study tool (The Bible Tool) is not advertised very well from
>     the CrossWire main page (at the top right "Read the Bible" link).  This
>     addresses one of the 4 top level visitors of CrossWire (consumers
>     seeking software, consumers seeking book addons to their software,
>     _consumers seeking to study the Bible_, contributors).  Originally,
>     CrossWire hoped to remain solely the developer of tools and for other
>     organizations to actually host The Bible Tool software, but things
>     haven't worked out with that yet, so we are the current host.
>     Currently 2 sites: CrossWire and The SWORD Project are under version
>     control in svn.  They should be mostly relocatable so people can check
>     them out locally and make modifications and commit if they are given
>     commit access.
>     Traditionally, I have made a hard stand to normalize on technologies
>     (db:firebird, http:apache, dynamic_html:java/jsp), but this has 'laxed
>     somewhat in the last couple years with additions like our wiki at
>     http://crosswire.org/wiki (not java/jsp based).  I am not thrilled about
>     this, but will not let my normalization policy prohibit us from using a
>     tool which will truly enhance our cooperation and productivity (couldn't
>     find a good jsp based wiki).
>     Again, thank you for the offer to help.  I'm not sure if I've
>     discouraged you, but I hope not.
>             -Troy.
>     Andrew Sterling Hanenkamp wrote:
>      > Disclaimer: I'm exposing my newby perspective on the project. I know
>      > nothing about the long term plans of the contributors/maintainers in
>      > reference to the web site and project management. I'm new to the
>     project
>      > and am risking stepping on someone's toes by saying this before I
>      > understand the project culture a bit more, but since this would
>     be the
>      > area I may be best qualified to contribute, here goes...
>      >
>      > I've been looking through the project resources related to Sword
>     and it
>      > looks like Sword has dabbled in a little bit of this and that
>     over time
>      > for project management. It looks like Source Forge was employed
>     to some
>      > extent for a bit, there are forums that seem to have mixed
>     success, the
>      > mailing list seems to be consistently useful, JIRA seems to have a
>      > smattering of tickets that are more or less used, and the web
>     site is a
>      > mixture of somewhat recent and somewhat ancient information with a
>      > number of broken links. All in all, it's a bit disorganized, a bit
>      > sparse, but not in horrible shape.
>      >
>      > The documentation of the Sword Project is spread thin and the web
>     site
>      > organization has a feeling of a structure that was initially
>     sound, but
>      > has slowly become mixed up over time. There are a lot of back and
>     forth
>      > cross links, for example, that make it difficult to figure out what's
>      > going on. Several times I've thought, "I remember seeing a link
>     for X,
>      > but where is it," and then had to click on several links back and
>     forth
>      > until I found the page that had link X on it.
>      >
>      > I would be very interested in helping with the site and project
>      > infrastructure and trying to get it into better shape. I think if
>     there
>      > was a little more front-end organization here, the project might
>     manage
>      > to pull in more volunteers a little more easily. Some better
>      > organization could also be a help to the existing community. As
>     it is,
>      > it kind of feels like you have to be an expert in the internals
>     of Sword
>      > before you can become an expert in the internals of Sword. (At least,
>      > this has been my experience so far trying to learn more about the
>      > development side of things.)
>      >
>      > My recommendation would be to restructure the site and try to
>     collapse
>      > out all but the key pieces. I'd consider using a tool like Trac or
>      > Drupal to provide the infrastructure for building the site. I
>     wouldn't
>      > want to eliminate anything someone really is using. For example,
>     if one
>      > or two of the JIRA queues are being used well, leave them, but
>     move the
>      > rest into the other system---this is just an example, I'm not really
>      > proposing that JIRA is something that should go away. Basically, I'm
>      > just suggesting that the structure of the site, documentation, and
>      > project tools be evaluated and then attempting to reduce the
>      > infrastructure into a small kernal that is useful and concentrates
>      > effort into one place so that things aren't quite so spread out.
>      >
>      > Anyway, I develop web sites, organize them, and occasionally
>     design them
>      > for a living. I would be willing to help here if there is any
>     interest
>      > in such help.
>      >
>      > Cheers,
>      > Andrew
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > sword-devel mailing list: sword-devel at crosswire.org
>     <mailto:sword-devel at crosswire.org>
>      > http://www.crosswire.org/mailman/listinfo/sword-devel
>     <http://www.crosswire.org/mailman/listinfo/sword-devel>
>      > Instructions to unsubscribe/change your settings at above page
> ------------------------------------------------------------------------
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

More information about the sword-devel mailing list