specifications should allow comments

Hi Jeff,

what about the whiteboard? Couldn't it be used for that?

Thanks for reporting

I don't know, what's that whiteboard thing? I never actually noticed it, as just "adding comments" feels so much more intuitive and consistent with malone. Besides, the name "whiteboard" makes me feel this is restricted to developers of a project team, and normal users cannot comment on a spec directly?

Hello Jeff,

On Wed, Sep 06, 2006 at 01:11:06AM -0000, Jeff Fortin wrote:
> I don't know, what's that whiteboard thing? I never actually noticed it,
> as just "adding comments" feels so much more intuitive and consistent
> with malone. Besides, the name "whiteboard" makes me feel this is
> restricted to developers of a project team, and normal users cannot
> comment on a spec directly?

There should be a link ('Edit whiteboard') to edit the spec's whiteboard in
the left column. That link currently isn't displayed but I committed a fix for
it today (Rev 4015). You should see it in the next production rollout which should happen in the next week.

Also note that the link is not available but you can access the +whiteboard
page by manually enter the address. (e.g. https://features.launchpad.net/distros/ubuntu/+spec/ltsp-dhcpd-autogeneration/+whiteboard)

Take a look at other specifications at https://launchpad.net/distros/ubuntu/+specs and see how people are using the whiteboard feature.

Do you think that covers your use case?

Thanks for the feedback,
--
Diogo M. Matsubara

Hello Diogo,
From a quick look at those specs, I indeed see what whiteboard means, somewhat. It's a progress indicator oftentimes. However, I still think that "comments" could be useful because:

- I think whiteboard is just for developers to indicate their issues and progress along the way
- comments should be for users without privileges, and they are "comments on the spec", not indications of progress. Reversedly, the whiteboard is a bit messy to hold comments, I think it would be a good idea to [allow] to separate the two features.
- comments have their own user interface design
- from other launchpad modules such as malone, users "expect" a comment function, because of consistency;
- it would be better visually, as you can do a proper separation of the two

Just my random thoughts :)

Oh yeah, and a big drawback of the whiteboard is that it overwrites itself. That is annoying, if you want to keep track of what has been done, you have to go back and copy-paste.

Thanks for raising this bug, and for everyone's comments.
We're creating a specification for this here: https://blueprints.launchpad.net/blueprint/+spec/spec-comments

I'm working on this feature at lp:~andrea-bs/launchpad/blueprint-comments.

Andrea, you rock!

I think you should do this bug in smaller steps. This is a multi-branch effort that will require some agreement with other developers about how to precede. This is one of the reason comments are not added yet.

I have some familiarity with this issue. The expectation is that these should behave like bug comments. To do this several branches need to be landed in a specific order. You should discuss each phase with a launchpad developer before you start hacking. Present an outline of what you want to do. the developer can show you code you can reuse.

1. Schema changes
    This adds comment storage or allow blueprint comments to be shared with bugs
    This requires a review by sabdfl after it has been removed by an engineer
    The branch will be landed to db-devel
2. Interface-model changes
    Create the definition and implementation of blueprint comments
    Consider extracting bug comment code to a mixin so that common code can be shared
    This will add doctests for the new object and maybe some unittests to verify they are robust.
3. View changes
    Add the views need to add, view, and edit (yes, let's plan for editing now)
    You may write unittests or doctests to verify the views do as intended
4 template change
    Add real templates and integrate the comments into other pages.
    Expose the behaviour to the world.
    Add a story test to verify that users can get to and from comments.

Ping me if you need my assistance.

Thanks for you help, Curtis.
You are saving a lot of my time :-)

Here's what I have understood:
2. Interface-model changes: I have to touch the packages lib.lp.blueprints.interfaces and lib.lp.blueprints.model.
3. View changes: lib.lp.blueprints.browser and lib/lp/blueprints/browser/configure.zcml.
3. Template change: lib/lp/blueprints/templates.

But I can't find the package/directory where to make 2. Schema changes.
Could you help me?

You will find the schema and the patches we have applied to it in

    ./database/schema

Each patch was landed with a branch. The patches are named in major-minor-patch format. They are applied in order when you run `make schema`

Note the style, SQL keywords are CAPS.
All begin with this statement:
    SET client_min_messages=ERROR;

All end with the patch number to check that the database is correct for the branch you are developing.
    INSERT INTO LaunchpadDatabaseRevision VALUES (2109, 61, 1);

Name your patch patch-2109-99-0.sql, the last line of your patch will be
    INSERT INTO LaunchpadDatabaseRevision VALUES (2109, 99, 0);

When you patch is approved to land, you will be given an official patch number to rename and update the patch too.

Fixed in db r8368 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8368>

On Mon, 2009-09-28 at 20:22 +0000, Edwin Grubbs wrote:
Fixed in db r8368 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad
> /db-devel/revision/8368>

Actually the revision includes just the interfaces and model changes. I still have to work on the webservice API and the GUI.