[395] in Project_DB
Re: Use of project-db by 1999 MR Projects
daemon@ATHENA.MIT.EDU (Mike Barker)
Thu Dec 10 23:26:13 1998
Date: Thu, 10 Dec 1998 23:22:44 -0500
To: "Robert V. Ferrara" <rferrara@MIT.EDU>
From: Mike Barker <mbarker@MIT.EDU>
Cc: Mike Barker <mbarker@MIT.EDU>, project-db@MIT.EDU, ganderso@MIT.EDU,
azary@MIT.EDU
In-Reply-To: <v03020915b295fb770fbc@[18.177.0.229]>
At 05:33 PM 12/10/98 -0500, Robert V. Ferrara wrote:
:)Mike, some replies below. Bill and I also thought it would be good to meet
:)after Tuesday's OCMG to discuss an approach.
:)
:)Cheers, Bob
:)
:)At 2:36 PM -0500 12/10/98, Mike Barker wrote:
:)
:)>I would suggest that instead of limiting the practice to 1999, we avoid
that
:)>problem by simply calling it "Office - MR".
:)
:)Done, see http://web.mit.edu/miki/bob_changes/index.html which is draft new
:)projects database home page.
1. What are the current changes?
Some poking around indicates that this is not the only page that was
modified. Since I don't know of any easy way to find out where in a thicket
of html pages there have been changes without having to visit every one by
hand, could you please indicate what the changes are, where they are, and
why they are.
(further thought indicated that I could check which files are in that
directory. It appears that the index.html page and one other -- whatin.html
-- may have been modified? What are the modifications, though?)
2. A long-term approach to change control
If the project database is going to be an operational database in use across
IS, we have to get out of the habit of changing things without public review
and comment.
We need to develop the habit of providing good visibility into the proposed
modifications and of providing sufficient time for public review and comment
before making changes.
We should consider something very close to the successful
source-reviewers approach that Athena has been using for a while now.
Basically, proposed modifications are posted to the list (for Athena, with a
short description and patch file). Reviewers can question or challenge
proposed modifications, or can approve them (on source-reviewers, an
explicit "yeah" expedites acceptance of the modification, or if no one says
anything, the proposal is accepted after one week). Questions require a
response, and unresolved disagreement escalates discussion of the proposal
to the release team.
We can use a very similar approach for changes to the project
database and associated HTML pages. Changes should be documented by a brief
description and rationale, plus an actual modified version if possible. The
description and rationale can be posted to project-db, with a pointer to
other materials where suitable. Readers of the project-db list should act
as reviewers.
In most cases, the "delay" to allow feedback will not be a problem. In
those exceptional cases where an expedited decision is needed, we can do
that by explicitly saying that we are doing so and why.
3. Some brokenness about the new additions
Incidentally, are we going to add pages under http://web.mit.edu/is for ad
hoc, commons, and office-MR? I.e., if I go to the database and click on "ad
hoc", it tries to open http://web.mit.edu/is/ad hoc and fails.
It may also be worth noting that the addinf.html page seems to be missing ad
hoc in the list of practices.
mike
