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(or
the active oj programmer), 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
