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

Request notifications

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

Collapse
2: Approved (response to 1)
Posted by Caroline Meeks on
Excellent idea Janine, thank you,. I will sponsor this.

Approve.

Caroline

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 think the point of this would be to lower the barrier for contribution as much as possible. Requiring a README for /contrib/ is a good idea, but for /works-in-progress/ we shouldn't require anything at all.

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.

Collapse
Posted by Roberto Mello on
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

Collapse
Posted by Bart Teeuwisse on
Approve,

/Bart

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. :)

I can't think of a better name either ;). So I have no objections at all if you go ahead and name it work-in-progress. Please not use-at-your-own-risk - the implications of that would be even worse, no (other packages are guaranteed to work)?
Ok, work-in-progress it is (I was only joking about the other name, though I do believe in truth in advertising!).
Hi,

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.

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.
One question: if you are working on a package should it be in works-in-progress/packages or just in works-in-progress?

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).

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.

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.

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. :)

Instead of a README file, why not a INCOMPLETE or WORK-IN-PROGRESS file that states the status right in the file name.
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.
Ooops, sorry. I need to learn the TIP rules better myself.

-Roberto

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.

Off-topic reply here
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.
It was in the chapter "High finanace or the Point of Vanishing Interest" in "Parkinson's Law" and the funding decisions were:
  • £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).
  • Anwyay, bikeshedding is the word that ended up in the lexicon, maybe because "coffee-arguing" or "atomic-plant-not-debating" just don't work as well :)
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.