wishlist: public whiteboard on branch pages

Martin Pool mbp at canonical.com
Wed Oct 25 04:35:33 BST 2006


On 16 Oct 2006, David Allouche <ddaa at canonical.com> wrote:
> Martin Pool wrote:
> > On Fri, 2006-10-06 at 13:37 +0200, David Allouche wrote:
> >> 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.

[...]
> 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.

Well, all these approaches could benefit from allowing people to
subscribe, but they don't *require* subscriptions to be useful.  We can
add that later.

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

I think if relations have got so bad that they need enforced permissions
to prevent people changing each others branches, then the product will
probably just fork.

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

I think adding a micro-wiki would be great.  (It works very well in
Trac.)  As you say, it's reusable in many other places.  To start with,
simply storing text and rendering it as text would be enough.

-- 
Martin



More information about the launchpad-users mailing list