Please Review: design doc for Project Ideas web application

Alexander Leidinger netchild at FreeBSD.org
Sun Mar 23 09:01:35 UTC 2008


Quoting "Murray Stokely" <murray at stokely.org> (Sat, 22 Mar 2008 14:26:35 -0700):

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

I never rejected to add technical stuff to entries. I think the same is
true for Joel. So far we either got technical comments, or not. So I
don't think this text reflects the reality. I don't mind if you write
the the current system doesn't have a rating system where people can
see personalized comments/opinions.

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

Yes, there's why I wrote 'entirely'... :)

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

Wow, this is a very nice feature.

> I updated this on the wiki to be more clear.

Thanks.

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

Yes. I just moaned about "voting", but what you seem to have
implemented is "rating with comments". That's what we need here. Good!

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

Sounds ok.

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

Great. Looks ok.

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

Looks ok.

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

As it looks currently, the developer rating and the user voting is done
in the same "slot". Shouldn't we separate this into two slots, so that
we have a rating value by developers, and an interest value from users?

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

I don't think I care much about the format (except maybe when I can not
determine what the change is to the previous status, but we will see).

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

We can refine this later when we see how usable the current approach
is. Just take care that we can extend the app later without roadblocks.

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

No objections... :)

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



More information about the freebsd-doc mailing list