Forum OpenACS Improvement Proposals (TIPs): TIP #27 (Rejected): Create a works-in-progress directory in /contrib
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
Or perhaps this will be irrelevant when we get the OpenACS package repository functionality working so folks can do installs via the network.
I assume there would be a better name for this though, since works-in-progress seems to imply that 1) all the other stuff is finished and 2) it is actually being worked on the stuff in there, but I think a big part of it would be abandoned/partly finished stuff that someone just wants to drop there in case it is useful to anyone else.
Therefore, I'm approving this.
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. :)
I think Roberto's suggestion is better. Or maybe page that lists the status of the contrib packages. On my case on particular snap shots it can go to contrib or work-in-progress. Goes back and forth.
And to be honest, in may case. There is a case of does-not-work-will-upgrade-later. I think either a single status page which list the current of all contrib packages. Or a status page on each package as Roberto suggests. From what I recall before I started to put my packages there, it was no criteria. The sole criteria was, you wanted to share your code. Or I guess that is what I have been told and understood.
Because putting it on a dir to give status seems to bring the barrier up again. And we may end up will a lot of dirs, like contrib, work-in-progess, work-halted, etc. Maybe a contrib/STATUS page can be used. Since I think most contrib people will have access to that page. We just update it from time to time when ever we commit new code.
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.
One objection: Putting something in a works-in-progress means which it is contrib worthy we then have to move the stuff in CVS (which as we all know is mostly unpleasant and has negative consequences). It also means that we would have to edit the avail file and will generally require someone with cvs admin rights to carry out.
A couple alternatives I would find preferable: either put the status in the .info file, create a contrib/pkgname/WORK-IN-PROGRESS file or README with the status, or add it to contrib in the normal place but do the work on a "work-in-progress" branch so that when peope check out head or a release they would not see the package and would have to do an explicit step to get the package.
Anyway, as long as people realize once something is ready and is moved to contrib it will either break peoples checkout or leave their checked out version stranded relative to the new contrib version and that is considered acceptible then go ahead with this. I don't like it though...
Hence my veto (I would like it to have some further discussion since we should at least consider the drawbacks here).
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.
Joel, I thought a TIP required 2/3 if there was a veto (no). Couldn't a TIP be approved if six OCT members approved? Why would the remaining three votes matter at that point, so why would it need to sit around for a week?
This is just a general question, unrelated to this TIP, I'm not sure this one has six votes yet.
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. :)
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.
- £10,000,000 atomic power plant -- minimal debate (2.5 minutes).
- £350 bike shed -- moderate debate (45 minutes).
- £21 for coffee at a meeting -- extreme and devisive debate since everyone knows about coffee (1h15m).
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.