** Using WeBWorK **

I realize that it would take some effort to see if a submitted correction is really better. One bug fix might cause anoter bug, and some of the changes might be a matter of style that others would disagree with.

<| Post or View Comments |>

We (the WeBWorK community as a whole) are at the beginning of a process to develop a procedure which will accomplish this task efficiently. We need both technical tools that make it easy to compare files (both the source and the output) in order to see what changes have been made and editorial procedures as to how to judge when one an "improvement" has been made or whther one has created a new related problem. Finally we want to create metadata that allows us to associate similar problems and to find problems meeting certain characteristics. Among others, John Jones at Arizona State, Jeff Holt at U. of Virgina and Bill Ziemer at CSU Long Beach have been thinking about this problem.

I'm assuming that your modifications are to problems in the rochester library (rochesterLibrary or rochester_problib) over which I guess Arnie and I can claim editorial control.

So as a start I'd like to suggest the following -- if you have suggestions as to alternatives, please let me know.

Send me a tarfile of your corrected problems (my suggestions for the format are below) and I'll review the changes and submit them to the CVS. I'll use BBedit difference engine available on Mac's to compare your submissions with what is already there and see how well it works. I also have some local tools using Userland Radio and Userland Frontier that allow me to display problems locally and compare how they look. I'll report back on what successes and difficulties. If some of these tools work we can try to port them to other platforms -- perhaps developing tools in perl/tk or tcl/tk.

Other issues, which I'm not addressing here -- but I'm open to suggestions -- involve giving attribution to problem fixes, maintaining metadata, organizing and pruning existing problem libraries (see http://webhost.math.rochester.edu/webworkdocs/ww/problemLibrary) and so forth. In the very long term I'd like to see an editorial board for problems set up-- perhaps in conjunction with the MAA and MathGateway project.

I'll try to see if I can set up a public "upload" directory on devel.webwork.rochester.edu or on the sourceforge site where people can upload contributions rather than send me email and attachments.

For format -- it would help enormously if you can send me the problems in a directory structure that mirrors the original:

e.g.

rochester_problib | set............ sr_un_1.pg sr_un_2.pg

That way I can quickly compare the new version of the problem with the old one.

If you have renamed the problems and this is too much trouble give me as much information as you can so that I can find the original problem to compare it with.

This is an important issue to address -- sorry that we don't yet have a complete answer.

-- Mike

<| Post or View Comments |>

Nandor

<| Post or View Comments |>

The current Rochester directory structure is a "generic" table of contents for a calculus book -- plus added topics. This form has its uses as well. The best result will be to have much of the organization of the files contained in a database that allows the presentation of multiple views. John Jones, Bill Ziemer and Jeff Holt have already done some work on this project, so they might like to comment on this approach.

I'd like to hear comments from others about what they would find useful, and suggestions about the technology and the organizational structure that would make a problem bank useful and feasible. I suspect that the organizational structure may be the harder aspect of the problem.

-- Mike

<| Post or View Comments |>

As Mike said above, Ziemer, Holt, and I are working on a project to organize/collate/redistribute webwork problems. I am hopeful that we will have an update by the end of the summer which will contain the rochester problems, and then some. I also think we will be posting directions for people who are willing to classify their own problems under our scheme.

As far as organization of problems goes, we are following a structure similar to what was done with the Rochester problems originally - organize them by generic tables of contents. We have looked at the mathdl hierarchy and I think our organization can map into that one fairly cleanly. The advantage of the current approach is that problems which go with a particular course are going to be close together in the hierarchy, whereas that is not so with the mathdl one.

John

<| Post or View Comments |>