Forum OpenACS Improvement Proposals (TIPs): TIP #27 (Rejected): Create a works-in-progress directory in /contrib

In my opinion, there is a certain quality standard that even works in /contrib should meet.  That is, they may be missing important features, require i18n work, support only one database, etc, and of course they have not been blessed or even looked at by anyone else in the community, but generally speaking what's there ought to work, bugs notwithstanding, in the opinion of it's author.  So that one can install something from contrib and expect to see some useful functionality, even if it needs additional polishing .

If we agree that that's a useful standard, then we need somewhere to put code which is being given to the community but does not meet even those minimal standards.  Like the unfinished research paper module, for example.  The work was done for Sloan but it was never completed, and although we may complete it someday it's not in  anywhere near usable shape today.  We have no problem with contributing this, but would not want to mislead people as to it's status by putting it into /contrib with other, much more usable works.

To this end, I propose creating a subdirectory of /contrib, tentatively named works-in-progress.  It would be up to the package owner's discretion to decide when to move a package from works-in-progress up to /contrib.  Moving a package out of /contrib requires community approval, as always.

=========

Changed to Approved by Roberto Mello

Wouldn't it be better/easier to just ask /contrib package owners to keep an updated README with the status of the package?

Or perhaps this will be irrelevant when we get the OpenACS package repository functionality working so folks can do installs via the network.

-Roberto

I realize now that this would be useful to get more code made public. It's better to have not-so-great code publicly available (but clearly labeled as such), than no code at all.

Therefore, I'm approving this.

-Roberto

Now that this is approved, we need to come up with a better name.  I understand Tillmann's concern.  The only problem is, I can't seem to come up with a better name!  Everything I can think of has the same problem, implying that the other stuff is in better shape than it really is.

Considering that Roberto is right, that this is only an issue until we have a download facility where uploaders can attach appropriate warnings, could we use works-in-progress as a temporary measure?  If not, how about some suggestions?

Maybe we could call it use-at-your-own-risk. :)

Ok, work-in-progress it is (I was only joking about the other name, though I do believe in truth in advertising!).

Procedural note:
According to our current rules (TIP 2), a TIP can't become Approved in less than a week.  That is, every TIP, even if voted Approved by two OCT members, must remain Proposed for a full week to give other OCT members a chance to veto (at which point it can go to a full vote).  The only exception would be if every singe OCT member approved.

Oops, sorry - I already created the directory.  I will remove it.

My concern with attaching any kind of note to a package is that human nature says that people won't read it.  What I expect will happen is that someone will see a package in contrib, say research-papers (or whatever it's called), get excited because that's exactly what they were looking for, and start working with it without looking for any readme or .info notes.  How many of us bother to look at what is in the .info files now - last time I looked, most of them still had the old aD info in them.

So this person will start running into problems, and since they thought this would be mostly working they'll either spend a lot of time trying to make it work, or come to the forums asking for help.  Either way, the situation has the potential to waste a lot of time and frustrate people.

I think that people will be more likely to notice the code's status if they get it from a directory that's clearly labeled.  No guarantees, of course. :)

Personally, I have no problem with telling people to "cvs rm" the package from works-in-progress and add it fresh into contrib/packages when it's ready to go.  You don't really lose the history, since the old files are all kept around for historical purposes, and starting with a clean slate when the thing is considered to be ready for contrib is not such a bad thing.  I think I read some discussion recently about how this was the right way to move things without breaking checkouts?

It is true that someone would have to do this for users who don't have commit rights.  I don't know how much of a burden this would end up being.

As far as the directory goes - I had created contrib/works-in-progress, and I assumed that everything would go there.  I don't feel a need to mark packages vs non-packages - hopefully someone getting something from that directory will be clued in to look carefully at what they're getting.

IMHO this is a temporarly solution.  Once we have a download repository we can accomplish the same thing there.  The only reason I brought this up now is that Sloan is being asked to contribute code that I am uncomfortable putting directly into contrib.  Presumably I'm not the only one who has this concern - meaning that there are other never-to-be-finished pieces of work out there that might get contributed if there was a way for people to do it.

IMNSHO, these relatively fine distinctions between "contrib" and "works-in-progress" are mostly and non-productive. It's easy to come up with equally legitimate reasons for having 3 or 4 or more such divisions, rather than two, as others here have already alluded to, which should be a clue. Using the hard-to-change physical organization of the CVS repository to control these various easy-to-change fine distinctions sounds like a bad idea to me.

Besides, is there really so much stuff in contrib already that it's too hard to sort out what's what? I don't think so. Nor will there be anytime soon.

At best, all this "works-in-progress" CVS location is providing is a rather poor band-aid for the fact that there's currenly no real information anywhere describing status of the various packages. Seems to me it is both easier and better to simply fix that problem directly. Requiring all contributed work in include some sort of README desribing the status of the code is pretty trivial, and a better solution.

Just put everything in "contrib". Include a README in your package explaining its status, etc. This currently adds basically zero extra work for contributors, so if your short term goal is really just to start getting more code into openacs.org CVS as easily and expeditiously as possible, this seems to be the way to go.

As far as methods to help sort and organize contrib, to make it easier for people to find what they want, etc., some of Jeff's ideas above sound worth pursuing.

I think the primary "quality standard for contrib" should simply be: The OpenACS community thinks the contributed code might be useful to some OpenACS users. If other additional standards should be applied, it's not obvious to me what they are or why they should be required.

Largely all merely IMO, of course. :)

Incidentally, this does sound somewhat like the apocryphal example of everyone debating about what color the web page should be, simply because it's easy to debate. I was sufficiently tempted to put my 2 cents in, but in the end it probably doesn't matter all that much, as long as whatever decision you folks allows people to easily contribute all the random code they think worth contributing, somehow, somewhere.

Another thing to keep in mind is that when we branch the 5.0 release anything that is not "releasable" in contrib or elsewhere shouldn't go onto the 5.0 branch. If we do manage to get away from monolithic releases it becomes even less of a concern.

btw, Andrew, the thing you are refering to is "bikeshedding" and predates the web by a fair bit. I think it's a pretty common maladay of online communities for some reason.

I recall it being the cost of cofee or of a coffee machine in Parkinson's original, not a bike shed. (Probalby Parkinson presented wrote different variations.) But yes, that's the concept.

I like the idea of putting the info in the .info file.

Then, you can see the status of the file from the APM before you install it.

And when we get a centralized repository, the repository code can display the current status of each of the packages, even sorting by that if we like.