wishlist: public whiteboard on branch pages

[David Allouche]

Martin Pool wrote:
> On Fri, 2006-10-06 at 13:37 +0200, David Allouche wrote:
>> There was some discussion initially about doing "branch discussions" in
>> the same way that we do bug comments, however this would have some
>> difficult implications. If you think you really want a public-writable
>> whiteboard for branches, I would be glad to braindump a few possible
>> tracks and their respective issues.
>>
>> I think your use case would be better served by Launchpad displaying the
>> branches that fully merge the branch being displayed, as suggested in
>> this bug:
>>
>> https://launchpad.net/products/launchpad-bazaar/+bug/30668
[...]
> Well, showing that would be very nice, but it doesn't actually serve the
> case I had here: I want to say "I'm *going to* merge this", though I
> haven't yet.  I think both features have value.

Okay here are some of the options I can think of to implement this.

== Micro-wiki ==

A simple text is associated to every branch (maybe a new
Branch.discussion column, maybe just the existing Branch.whiteboard),
and is writable by all logged-in users.

Benefits:
 * Easy to implement
 * Easy to understand and use
 * Never grows out of control

Drawbacks:
 * Does not automatically track authors and dates.

== Bulletin board ==

An append-only collection of messages is associated to every branch.
Similar to bug comments.

Benefits:
 * Familiar UI
 * Easy to use
 * Tracks authors, date and history of the full discussion

Drawbacks:
 * Needs additional design to keep the length of the discussion in check
over time. We do not want to have to display dozens of out of date
comments on a branch page.

== Per-user comment ==

Each user has the option to add exactly one personal comment on each
branch. A user-comment can be edited only by the user owning it. The
user comments on a branch could be ordered last-modified last. Clearing
the text of a user-comment deletes it.

Benefits:
 * Track author and date of each comment
 * Should never grow out of control (except if abused)

Drawbacks:
 * Unfamiliar concept
 * Does not allow tracking the history of the discussion

== General remarks ==

All approaches call for the implementation of a "discussion
subscription" functionality, allowing users to receive email
notifications when something is changed or added in the discussion.

On the importance of tracking authors: the SABDFL previously opposed to
allowing product owners from editing branches associated to their
product because in some cases there can be strong tensions between a
product owner and some of the contributors. In the centralized version
control world, that translates into people just going away or in a fork.
In the decentralized version-control world, what can (and does) happen
is a gradual shift of the developer community away from the difficult
maintainer.

== Conclusion ==

My preferred solution is the micro-wiki, just because it's the simplest
possible way of doing it. Additional features (history tracking, bans,
access control, etc.) can be easily added later and it's probably widely
reusable in many places on Launchpad. But before doing it we need the
SABDFL to revise the policy against allowing people other than the
registrant from editing branch details.

My least-preferred solution is the bulletin-board, because of its
append-only nature.

-- 
                                                            -- ddaa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/launchpad-users/attachments/20061016/08ac3b7a/attachment.pgp