[sword-devel] Taming Wild Threads (was: Getting stuff done (Re: External links))

[Daniel Owens]

Chris Little wrote:
> 
> Daniel Owens wrote:
>> 2. The Crosswire repo is a bottleneck. I think Chris needs help to get modules through in a timely manner. More people need to be involved at that step. PLEASE let's find a way to reduce the turnaround time for module publishing. I'm willing to contribute there.
> 
> There are essentially two independent issues here (I would guess). One 
> is the time it takes to get a module into the beta repository and one is 
> the time it takes to get a module from the beta repository into the 
> public repository.
> 

Fair enough.

> 1) Getting a module into beta requires submitting a validating XML 
> document to me and requires that I have the time to check/fix/upload it. 
> I still receive more invalid content than valid, in spite of the fact 
> that I repeat and repeatedly post the mantra "validate, validate, 
> validate" at every opportunity. Submitted .conf files also invariably 
> require some amount of work (sometimes extremely minimal) to bring them 
> up to the standard we require.
> 
> My own ability to work on submissions varies with my schedule of school, 
> teaching, testing, & conferences. I usually have time on weekends to 
> catch up with my queue, but I'm less excited about delving into a queue 
> full of un-validated content.
> 
> The moral being: validated content can generally move into the 
> repository relatively quickly.
> 

Also fair.

> There are certainly others who have permission to post content into the 
> beta repository, and I welcome their doing so, provided our standards 
> don't get thrown out the window and provided that they don't cause 
> permissions problems like we've had in the past (but I think this latter 
> point is no longer such an issue as the server corrects incorrect 
> permissions via cron and the sticky bit).

Perhaps I spoke too quickly on this one, but do you think you have 
enough time to do this? Others may have permission to post modules, but 
do they respond to the modules at crosswire.org? Part of shepherding 
modules through the process ought to be coaching module developers on 
how to produce better source files. A bit of back-and-forth interaction 
when a non-validating source file is submitted would go a long way to 
educating module creators, making your life easier the next time that 
person submits a module. It's not just about maintaining standards but 
about education, and that requires time (unfortunately just adding 
content to the wiki doesn't do the whole job of educating module 
creators...). This is an honest question--if an inbox full of 
unvalidated source files sinks your motivation to clear the queue, 
perhaps you need some help. Just a thought.

> 
> 2) Getting content from the beta repository into the public repository 
> basically requires sufficient testing. I feel like we have an abundance 
> of opportunities for people to help here. We have RSS feeds and the 
> InstallMgr itself to alert users when new/updated content has been 
> uploaded. We have the module testing wiki page for people to make bug 
> reports/comment on issues. And we have the bugtracker for people to log 
> trackable bugs (in beta or public modules).
> 
> I've posted about 10 new modules in the last couple weeks and received 
> zero feedback. I've seen no evidence of testing. Without a modicum of 
> testing, this content won't be moved to public.
> 
Hey, c'mon. I wrote back right away about the NVB! :) The beta module 
testing page is good, but I would appreciate more explanation for the 
following items:
	Any eternal loops or other structural problems? (What does this mean?)
	Conf Problems? (Does this simply mean that the basics are there as 
defined on the wiki?)
	Ready for import into main repository? (Does this simply mean that all 
other categories are satisfied? What if some front-ends don't properly 
display the module?)

>> 4. Yes, let's maintain source files for ALL modules, only making them public if it is appropriate. That will facilitate bug fixing as well as new module creation. I obtained permission from Crossway to view the ESV source once, and that file had been lost. I still can't figure out how to create a source file that produces a compiled module with the features of the ESV module, and it's been over a year since I started working on it. It's NOT a matter of just using valid OSIS--you have to divine or accidentally discover a hack solution. If working modules were available as examples that would help folks like me and Peter learn how to create good source files.
> 
> This sounds like two unrelated issues:
> 1) maintain source files, and
> 2) provide better support (tutorials?) for OSIS.
> 
> 1) Personally I maintain my own sources and those of all submissions. 
> I'm not generally open to sharing these publicly, but I keep them in the 
> event that updates are necessary.
> 

Please make a few of your source files public. That would help us a lot! 
If there aren't copyright issues, why not make them available?

> 2) I think we could do more to support OSIS generally. I would like to 
> propose that we create an [osis-user] list on crosswire.org. This used 
> to exist, hosted at WTS, but is now gone. I think it might be a good 
> idea for CrossWire to adopt some of the OSIS support and evangelism 
> functions that have been more or less abandoned by its initial financial 
> supporters, seeing as they have adopted the position that OSIS is a 
> complete standard and therefore their work is done. Indeed, OSIS is a 
> complete and usable standard, but there are still support needs, and I 
> think we could help with that--especially considering we've likely got a 
> majority of people interested and knowledgeable in OSIS somehow 
> affiliated with CrossWire.
> 

Sounds good.

> So I'm proposing a new [osis-user] and a new website (we used to host a 
> bunch of sample OSIS files, but they were all OSIS 1.1.1). The new 
> website could be a separate wiki, for example. But I think we'd want to 
> separate and segregate general OSIS material from Sword material--hence 
> the separate wikis. Feel free to disagree with the separateness.
> 

Sounds good. I have no problem with the separateness, but it is 
frustrating if you try to take an ideal OSIS file and compile it for 
SWORD but come up with unexplained problems.

>> 5. I've only worked at learning OSIS and TEI, not ThML, but I have discovered that PRISTINE OSIS doesn't always work with SWORD, and ironically GnomeSword supports OSIS the best. Credit should go to Karl and the GnomeSword team for that. The wiki page presents an ideal, but in reality there is a SWORD OSIS schema that is unpublished and unarticulated. PLEASE, can we have an AUTHORITATIVE catalog of supported mark-up and a place to request valid OSIS mark-up that we want supported? If the former doesn't sound feasible, surely the latter is. No one should expect complete support of the OSIS schema, but things like headings, footnotes, and crossreferences should just work, but they sometimes don't. Additional markup should be able to be added, though.
> 
> Indeed, someone should do this. Why not you?

I haven't sufficiently honed my divination skills. :) I can definitely 
pitch in, but because I am not a programmer I find myself lacking the 
confidence to make assertions about does and doesn't work (I know the 
source of display problems can be in the encoding of the source file, 
osis2mod, the SWORD engine, or a specific front-end. How do I tell which 
is the cause when I can't read the source code with understanding?). 
Should I just try to police the wiki and make sure that what is 
recommended there actually works?

> 
> I presume the comment about a SWORD OSIS schema was rhetorical, because 
> we do use the standard schema. When you import, osis2mod can do strange 
> and wonderful (sometimes less than wonderful) things to your markup to 
> make processing/rendering easier, but that's none of the encoder's concern.

Yeah, it was tongue-in-cheek, but as with all such comments there is a 
kernel of truth. Validating is one thing, but validating relates very 
little to the successful display of content. If you can't just take the 
schema and know that anything you do based on that schema will work, you 
have a shadow "schema" out there. It shouldn't be the encoder's concern, 
but it is. What encoder wants to produce a module that doesn't work? 
Again, for non-programmers, we think the cause is our encoding...

> 
> To find out which features are translated from OSIS (or TEI/GBF/ThML) to 
> HTMLHREF or RTF or BibleTime's format, you would need to look at the 
> filters, such as OSISHTMLHREF. Even if features are handled by the 
> filters, potentially they will not be handled by frontends that use 
> them. So you may also need to check for support of the features within 
> the frontends themselves. Then hopefully you'll stick all of that 
> information about which frontends support which markup into a wiki page. 
> (And by suggesting that you get the ball rolling on this, I don't mean 
> to suggest that others shouldn't help with this.)
> 

I have to agree with Matthew Talbert on this one. It's just a bit 
daunting for me to look at the source code, and then not every front-end 
will display it all. I guess I can try to put my money where my mouth 
is, but be fore-warned that the results could be dodgy. :)

> --Chris
> 
> _______________________________________________
> 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
> 

Thank you for responding to my email. Things are becoming clearer for me.

Daniel