Troy,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.
<br><br>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.
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.
<br>
<br>
Cheers,<br>
Sterling<br>
<br>
P.S. Is there an IRC channel somewhere?<br><br><div><span class="gmail_quote">On 5/9/07, <b class="gmail_sendername">Troy A. Griffitts</b> <<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Andrew,<br><br>Thank you for offering your help regarding our project websites. I<br>agree with your assessment; a reorganization would be a welcomed change.
<br> Here are a few of my specific thoughts on the matter:<br><br>Most frontend projects have their own website, bugtracker, source<br>repository, etc. CrossWire makes these services available from our<br>server (apache/tomcat, jira, svn, ...), but most projects still choose
<br>to use sourceforge or another site-- which is fine. I am hesitant for<br>us to install something like Trac, when sourceforge and google are<br>focused on providing such services.<br><br>The goal of the main CrossWire page is to initially welcome all kinds of
<br>users and filter them to the correct sub-site tuned to their interests.<br> Organizing this is a challenge-- end users of Bible software want<br>something very different than developers looking for API examples.<br><br>
The SWORD Project site (<a href="http://crosswire.org/sword/">http://crosswire.org/sword/</a>) seems more geared<br>to developers and contributers than it does to end user, but this is the<br>only place for end users to find certain information. For example it
<br>has a facility to let project leaders post news items about their<br>project. This should probably be moved to the CrossWire main page.<br>Module downloads are also under the SWORD site, though there is a link<br>directly from the main CrossWire site.
<br><br>The current site layout was contributed by good-hearted people just<br>learning about JSP includes. The current page structure makes difficult<br>the task of adding a side menu choice, and the locations are not very
<br>modular. I have no strong feelings which would prevent unwinding the<br>complexity to a simple layout.<br><br>Our online study tool (The Bible Tool) is not advertised very well from<br>the CrossWire main page (at the top right "Read the Bible" link). This
<br>addresses one of the 4 top level visitors of CrossWire (consumers<br>seeking software, consumers seeking book addons to their software,<br>_consumers seeking to study the Bible_, contributors). Originally,<br>CrossWire hoped to remain solely the developer of tools and for other
<br>organizations to actually host The Bible Tool software, but things<br>haven't worked out with that yet, so we are the current host.<br><br>Currently 2 sites: CrossWire and The SWORD Project are under version<br>control in svn. They should be mostly relocatable so people can check
<br>them out locally and make modifications and commit if they are given<br>commit access.<br><br>Traditionally, I have made a hard stand to normalize on technologies<br>(db:firebird, http:apache, dynamic_html:java/jsp), but this has 'laxed
<br>somewhat in the last couple years with additions like our wiki at<br><a href="http://crosswire.org/wiki">http://crosswire.org/wiki</a> (not java/jsp based). I am not thrilled about<br>this, but will not let my normalization policy prohibit us from using a
<br>tool which will truly enhance our cooperation and productivity (couldn't<br>find a good jsp based wiki).<br><br>Again, thank you for the offer to help. I'm not sure if I've<br>discouraged you, but I hope not.
<br><br> -Troy.<br><br><br>Andrew Sterling Hanenkamp wrote:<br>> Disclaimer: I'm exposing my newby perspective on the project. I know<br>> nothing about the long term plans of the contributors/maintainers in
<br>> reference to the web site and project management. I'm new to the project<br>> and am risking stepping on someone's toes by saying this before I<br>> understand the project culture a bit more, but since this would be the
<br>> area I may be best qualified to contribute, here goes...<br>><br>> I've been looking through the project resources related to Sword and it<br>> looks like Sword has dabbled in a little bit of this and that over time
<br>> for project management. It looks like Source Forge was employed to some<br>> extent for a bit, there are forums that seem to have mixed success, the<br>> mailing list seems to be consistently useful, JIRA seems to have a
<br>> smattering of tickets that are more or less used, and the web site is a<br>> mixture of somewhat recent and somewhat ancient information with a<br>> number of broken links. All in all, it's a bit disorganized, a bit
<br>> sparse, but not in horrible shape.<br>><br>> The documentation of the Sword Project is spread thin and the web site<br>> organization has a feeling of a structure that was initially sound, but<br>> has slowly become mixed up over time. There are a lot of back and forth
<br>> cross links, for example, that make it difficult to figure out what's<br>> going on. Several times I've thought, "I remember seeing a link for X,<br>> but where is it," and then had to click on several links back and forth
<br>> until I found the page that had link X on it.<br>><br>> I would be very interested in helping with the site and project<br>> infrastructure and trying to get it into better shape. I think if there<br>> was a little more front-end organization here, the project might manage
<br>> to pull in more volunteers a little more easily. Some better<br>> organization could also be a help to the existing community. As it is,<br>> it kind of feels like you have to be an expert in the internals of Sword
<br>> before you can become an expert in the internals of Sword. (At least,<br>> this has been my experience so far trying to learn more about the<br>> development side of things.)<br>><br>> My recommendation would be to restructure the site and try to collapse
<br>> out all but the key pieces. I'd consider using a tool like Trac or<br>> Drupal to provide the infrastructure for building the site. I wouldn't<br>> want to eliminate anything someone really is using. For example, if one
<br>> or two of the JIRA queues are being used well, leave them, but move the<br>> rest into the other system---this is just an example, I'm not really<br>> proposing that JIRA is something that should go away. Basically, I'm
<br>> just suggesting that the structure of the site, documentation, and<br>> project tools be evaluated and then attempting to reduce the<br>> infrastructure into a small kernal that is useful and concentrates<br>
> effort into one place so that things aren't quite so spread out.<br>><br>> Anyway, I develop web sites, organize them, and occasionally design them<br>> for a living. I would be willing to help here if there is any interest
<br>> in such help.<br>><br>> Cheers,<br>> Andrew<br>><br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________
<br>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel
</a><br>> Instructions to unsubscribe/change your settings at above page<br><br></blockquote></div><br>