Please Review: design doc for Project Ideas web application

[Alexander Leidinger]

Quoting "Murray Stokely" <murray at stokely.org> (Sat, 22 Mar 2008 00:16:05 -0700):

> [CCing current ideas.xml maintainers and heavy contributors]
> 
> I've written up some design thoughts and developed a mock web
> application in Python/Django to demonstrate the direction that I think
> we should move the ideas database to.

My overall opinion: great! Improvement suggestions below.

> The main drawbacks I see with the current system include :
> 
>     * Strict XML schema requires careful text editing in a tedious
> file format to add new ideas to the list.
>     * Anyone can propose an idea, but there is no feedback mechanism
> to separate the good ideas from the very bad ideas on the list.
>           o Some very senior developers have vehement objections to
> prominently placed items on the current list, but have no avenue of
> listing their alternate point of views on the project.

That's a shame. Unfortunately this needs a change in the behavior of
such developers, not a change in the presentation layer. So it is not
really a drawback of the current system. Please fix this part in the
wiki.

>           o It is not possible to see the ideas with the most recent
> "buzz" of users commenting/voting positively on them.
>     * There is no notification mechanism when new ideas are added to the list.

Sorry, this is not entirely true. Committers should have no problem to
get a notification in case they are interested. Either with their own
mailfilter, or by using our dfilter (or how the name if this thing is).

>     * Searching / sorting is primitive.
> 
> And some of the many new features that I think a web app would give us include :
> 
>     * Allow anyone to propose a new idea online.
>     * Allow anyone to comment and vote on previously proposed ideas.

What is this voting supposed to tell us? If users vote for features
they want to see, then I think it's a great idea. We would get feedback
what is the most desired stuff.

If developers vote against an entry, it's a bad idea. Voting (which is
by definition a binary pro/con for an item) is not what we need to do
here. Developers need to review with a technical (or legal) argument
against something. Just a "I don't like this" or "this is bullshit" or
"this is not a good idea" without an explanation why will result in a
very negative image and people will refuse to submit ideas.

The screenshot suggests you want to use it for rating by developers. As
said, in this case a simple voting is not enough. The Google SoC webapp
seems to better in this regard, it allows to give comments. The rest is
policy (the moderators should remove negative ratings without
appropriate comments and the person which did this rating needs to be
notified about/before this removal so he can take appropriate action
like improving the comment or adding his rating again with a better
comment).

So basically my comment for this is: an "interest" value for users (simple
voting), instead of rating would be better for the voting part. To rate
an entry by developers there needs to be more than a simple voting
interface.

>     * Provide an RSS feed of the newest ideas.

RSS should also be possible for the current one, so this is not unique
to a web app.

>     * Provide an RSS feed of the comments/votes for any specific idea.
>     * Export the entire ideas list to something closely approximating
> our existing ideas.xml file (so that we could augment rather than
> replace the current system, if desired).

I have no problems if the ideas list is replaced with such a web app.

>     * Allow one to sort and search the ideas list by category,
> proposer, votes, summary title, or full text.
>     * Anonymous ideas/comments are hidden by default until cleared by
> a moderator.
>     * Moderator bits to be set for certain users so that they can
> moderate the above (can subscribe to an rss file for unmoderated ideas
> and comments needing their attention).

What about email notification? Personally I prefer email over RSS for
something like this (I can read email from more places than I can read
RSS stuff).

>     * Import functionality to import the current ideas.xml file.
> 
> Screenshots and details on the wiki here :
> http://wiki.freebsd.org/IdeasWebApp.  Most of the above functionality
> was implemented in a couple of hours based on the existing static CSS
> stylesheets from freebsd.org for the presentation.
> Login/authentication is a big remaining hurdle if we want to avoid
> making everyone create yet another account.  I will look at
> integrating it with OpenID later this weekend.
> 
> Would like to hear additional ideas about this proposal, and any

Please add "difficulty" and "complexity" on the "enter an idea"-page.
Both can be normal text fields. For difficulty we could give examples
of easy/medium/hard or "expert needed"/"entry level" or something like
this. For complexity maybe something like "touches a lot of different
subsystems" or "self contained" or something like this.

What about predefined "tags". SOC could be one tag the maintainers
create and the "add" or "modify" part of the webapp would convert this
into "Suitable for Summer of Code () yes () no".

If wee allow free addition of ideas, we also need a public/private
thing. Newly added ideas are private by default and need to get changed
to public by a maintainer. This would block "semi-spam" (I don't talk
about spam in the sense of viagra commercials, but spam in the sense of
"FreeBSD is dead, use Linux" stuff or "replace ls/... with gnu
fileutils"). So far I didn't got very much of such stuff, but I'm sure
with an automated system this would increase.

It may also be better to have a separate text field for the
requirements. All entries need the requirements section, and we could
check this way if someone entered some requirements or not (ok, would
be very simple, like "is there more than only whitespace"), but at
least we can give feedback that it is a requirement to list
requirements.

> concerns about replacing or at least augmenting the static xml system
> we currently use with a web application.

Augment until we think it is ready for public consumption, then
replace. This way we can fix the rough edges while getting a benefit
already out of it.

Bye,
Alexander.

-- 
      ...and that is how we know the Earth to be banana-shaped.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137