Eric, I am sorry that I am responding to your e-mail so late. Thank you very much for such a detailed and well-thought out response to some of our documentation software/management issues.
I don't know that we are quite ready to migrate to a Trac software management system, as we're pretty comfortable with our SourceForge site, but I do appreciate the suggestions. However, I do think that two (2) of your suggestions have some real merit, and should be acted upon. The first suggestion has to do with how we organize or categorize bug reports. I'm going to repost this section of your message and ask the other programmers for some comments. The other suggestion about allowing users to offer payment for bug fixes and small feature enhancements also seems to have some merit, and I know it has been mentioned before. I'm a little nervous about it, but I'm willing to put aside some of my concerns to give it a try. I hope it would be a good thing for both users and programmers at the end of the day. Let me cook something up, and I'll let everyone preview and comment. Thank you for your involvement. You were'n't being ignored, I'm just now getting around to cleaning out my Gmail inbox. The Sunburned Surveyor On Tue, Apr 22, 2008 at 4:36 PM, Eric Jarvies <[EMAIL PROTECTED]> wrote: > hello everyone, > > have you considered instead using a subversion/trac setup? the nice thing > about this setup is that it eliminates a lot of redundancy as it relates to > application documentation. for example, as bugs, feature requests, etc., > are reported, those same entries can then be re-purposed as documentation. > if the repo is setup correctly from the get-go, meaning end-user gui stuff > like buttons, menu selections, operations, etc. are indexed in the > bug/feature request menu selections, and associated with the respective > classes/interfaces, then this allows non-programmers to easily report a bug > or feature request to the right place. an example of what i mean is this: > go to openump at sourceforge and select 'submit new bug' and look at the > 'category' pull-down menu selections. in this menu the user has: > interface > jts > misc. > openjump > plugin > wfsplugin > the above selections serve no useful purpose for the average user, who in > all likeliness will be reporting the majority of the problems/bugs. this > means it serves little purpose for those who may work on correcting the > problem. bug/ticket reporting should be designed for the end user, not the > programmer. the association however is what is important to the programmer, > and making sure that the ticket that was reported is associated with the > correct page/portion/snippet of code that in fact is responsible. this > means each source code document should have a plain english reference in > it(commented out), or multiple references throughout the document as is > needed/warranted. > imo, the easiest and best way to do this is by using the gui elements, such > as menu items, icon/button items, and contextual menu items as the means of > reference. thus, if i was using oj, and encountered a bug, or have an idea > of how something could work better(feature request), the oj repo should > offer me the following when i am submitting a ticket: > Submit New Ticket: > pull-down menu #1: > bug > minor(does not work correctly) > medium(works intermittently) > major(does not work) > feature request > core > plug-in > spelling correction > menus > help > operations > appearance > menu > icon > layout > > pull-down menu #2: > vista > xp > os x > linux > > pull-down menu #3: > File > Edit > View > Layer > Tools > Queries > Spatial Query > Attribute Query > Simple Query > Analysis > Generate > Warp > Edit Geometry > QA > Edit Attributes > Generalization > Measure in Feet > Customize > Scripting > Image > Plugins > QA > Window > Help > in the above shortened example, lets say the user selected Bug, OS X, > Tools > Queries > Spatial Query . upon doing so, the respective page(s) of > source code that is responsible for 'Spatial Query' should associated. when > the user writes a summary and submits the ticket, at that point it is > immediately associated with the proper source code page(s). this way, when > a programmer looks to address the issue, he need not hunt around trying to > locate it's exact location. furthermore, upon ticket submission, the user, > and any other user that may view the ticket, can see it's respective > association/source code. > of course, this means that during the setup of the initial repo, all of this > association has to be done. this is something i am willing to do, but will > require on you(programmers) who are familiar with the entire inner workings > of oj, to help me. of course, once it's done, then thereafter it's just a > matter of properly commenting any new source code pages/code snippets in > existing pages. > anther suggestion i will make is that once the above is completed, we take > and create donation pools for any/all bug and feature requests(tickets) that > are open on the site. we create a means by which users can commit 'x' > amount of money towards a ticket(bug fix or feature addition). we also > create a means by which oj programmers can note their best estimate of how > many programming hours will be required for said ticket. for example, let's > say i filed or found a previously filed ticket for a feature request that i > too would like to see implemented. i then want to stimulate some community > activity by putting some money where my mouth is, electing to commit $200usd > towards the ticket. the ticket indicates that 4 oj programmers have > determined it will take about 5 programming hours to complete, and the > industry rate for respective programming work is $50usd per hour, making the > ticket valued at $250usd, and meaning it needs only another $50 committed to > it in order to make it viable for rfp/solicitation. any of the oj > programmers could of course tackle it and earn that money, or, the ticket > could be submitted to guru.com, rentacoder.com, or any number of other > resource sites that bring programmers together with customers. > i make mention of this because most of the users of oj, and other open > source software projects, have a specific need they need served. if/when > the software does not entirely serve that need, they would be inclined to > spend some money to make it happen. i happen to be one of those people. > but in order for this to be productive, it needs to be organized, and right > now, the oj project is spread and scattered about, and thus it is hard for a > community of users to focus in on something, and instead right now it is > only individuals that are able to focus, and only on their specific > priority(s). and so this is why i make mention of this, and offer to invest > my time and money in helping centralize the project. > right now i have an osx install package for oj, that installs oj to the > applications folder and simply uses the openjump.sh to execute the app. but > am working towards creating a real application using jar bundler, wherein > all of the files are contained within the openjump app package. but before > i can venture into that territory, i need to better understand oj, and so > that is what i am doing now. of course, i have to seek advice from > programmers, to explain to me things i am unfamiliar with. and because oj > does not have an organized repository(in the sense i've described above, > from a non programmers point of view), this process is more painstaking, > especially for non programmers like myself. > regarding svn/trac: > with both subversion and trac, anonymous user settings can easily be > adjusted/set, thus confining spam to easily removable posts. using ssh > admin can easily create new user accounts for both svn and trac, again, > adjusting settings accordingly per user. > i setup a sample at http://trac.ericjarvies.com (svn.ericjarvies.com) at my > webfaction.com host. you can logon using test/test. if interested, i could > spend a few days stylizing it for oj, and setting up an example flow of what > i've described above, as it relates to bridging the gap between end users > and programmers, as it relates to ticket filing and their association with > the actual source code, as well as re-purposing tickets so they also serve > the end user documentation. also, the hosting i would donate would instead > be at slicehost.net, so that the so admin could have full control over the > slice/server, being able to soft/hard reboot as and wen is needed, as well > being able to apt-get/install whatever software is needed. > > if interested, i would donate the hosting 1 year at a time, and would agree > to make sure to pre-pay for the hosting 3 months before it expires each > year. this way, if i go broke, lose interest, or die, oj users have 3 > months to figure something out before the hosting expires. i know that > goole, and others offer some fairly > > the trac wiki works fine, and there are plenty of 3rd party add-ons that > extend it's functionality. > > perhaps we could take this opportunity to setup the svn repo trunk with oj, > as well as branches for os x pp, os x intel, linux, windows, etc. i have > personally indexed about 30 bugs oj has on os x ppc, along with dozens of > features enhancements and requests, but have not bothered posting them to > the sourceforge repo because that repo is not organized in such a way as > mentioned above, nor does it seem to have much going on, or many paying > attention to it. > > trunk: > openjump core > > branches: > vista > xp > os x ppc > os x intel > linux > > also, centralizing oj on it's own slice would also allow all images and > attachments to remain in the same place, so that if the site needs to be > moved sometime down the road, all of it's elements are centralized and > together in the same place. also, this makes backing-up an easy process... > and slicehost has nice backup routines and additional placs btw. > > in addition, we could setup geoserver, mapserver, postgresql, mysql, php, > and other server-side applications that could serve as a centralized means > of testing/working with the openjump client software. we could populate the > map server(s) with plenty of examples(i have lots of vector and raster files > i could personally donate for this purpose), and over time could build a > nice repo of all things oj related... from the client to the server and > everything in-between. > > let me know what you think. > > ? > > eric > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
