Please Review: design doc for Project Ideas web application

Sat Mar 22 21:26:37 UTC 2008

On Sat, Mar 22, 2008 at 1:42 AM, Alexander Leidinger
<netchild at freebsd.org> wrote:
>  My overall opinion: great! Improvement suggestions below.

Thanks for the many suggestions, comments below.

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

I reworded it.  How is this:

"Many senior developers have very different opinions about technical
ideas. The current system does not provide an avenue for them to list
alternate points of view, add detailed technical comments of
suggestions or criticism, etc.."

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

Ok, but non-committers may also be interested in this.  And a
notification with all other CVS changes isn't that useful.  The new
system would allow one to have RSS feeds for specific searches for
example, so one could only get a notification when a new filesystem
project with difficulty <= 3 and at least one positive comment has
been posted.

I updated this on the wiki to be more clear.

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

Yes, users and developers.

>  If developers vote against an entry, it's a bad idea. Voting (which is

I think there are entries on our current list that some developers
think are a bad idea, and others think are a great idea.  At least
that has been the case in the past and I don't think necessarily that
100% of the ideas need to be agreed upon by 100% of committers,
especially once we have a mechanism for alternate points of view to be
attached as comments and votes to the ideas.

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

Yes I agree.  We can put up some text on the vote/comment submission
form reminding people of this, and if necessary we can more strongly
moderate the comments, and certainly at least warn users that
profanity is not helpful.

>  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

I was confused why we had a miscommunication at this point, then I
realized I didn't post a screen shot of the actual individual idea
page.  Everything you proposed about linking comments with the votes
is already implemented.  I've added a new screen shot to the wiki.

The main UI change is now we only show idea summaries on the main
page.  You have to click on the summary to get to the full idea page
which includes the full text body about the idea, and all comments and
votes that have been left about that idea.  With the inclusion of
comments and voting there is far too much content to all be put on one
page once I import all of the existing ideas from ideas.xml.

So now there are three screenshots posted.

The main screen.
The idea submission screen (what happens if you click the "submit
idea" link on the main screen).
The idea detail screen (what happens if you click the title of an idea
from the main screen).

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

Yes I agree with all of this and I'm sorry I didn't post more
screenshots to make it clearer.  I think we are in complete agreement
about this.  Let me know if there is more.

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

Sure, we can have the web app send out some emails (I've Avoided this
so that I don't have to think of all the abuse cases) or at the very
least have a script in cron download the rss and turn it into an email
and send it out.

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

I like the tags idea very much.

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

Definitely.  They'll be unmoderated by default, and hopefully we can
give out a half dozen moderator bits to various freebsd committers to
help.

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

There are two approaches we can take with the different text areas for
requirements, difficulty level, time estimates, etc.  We can either
have separate text fields for all of them, or one large text field
pre-filled in with something like

"Your project idea here

Requirements:
* example: Familiarity with C language.
* Familiarity with TCP/IP RFCs.

Difficultly level: moderate
"

I lean more towards having a single text field, pre-filled in the way
we'd like to see it, rather than having many different text boxes we
must deal with.

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

Sounds good.  I think in fact we can very easily augment it like this :

1. Import all ideas.xml into this system, so that all existing ideas
are open for comment/voting.
2. Implement export to ideas.xml feature.
3. Change the xsl file in the static web build to include a link next
to each idea that says "Leave a comment about this idea." or, if
comments have been made, "View comments by others about this idea."
and just have those links go to the relevant idea in this app.  That
just means we need to add an "idea_id" integer field to the existing
ideas.xml file, so it knows how to construct the appropriate links for
that idea (http://webapp/ideas/<idea_id>).

         - Murray