Date: Sat, 22 Mar 2008 09:42:25 +0100 From: Alexander Leidinger <netchild@FreeBSD.org> To: "Murray Stokely" <murray@stokely.org> Cc: freebsd-doc@freebsd.org, loader <loader@freebsdmall.com>, freebsd-www@freebsd.org, Robert Watson <rwatson@freebsd.org>, Matt Olander <matt@ixsystems.com> Subject: Re: Please Review: design doc for Project Ideas web application Message-ID: <20080322094225.5bcdd5f5@deskjail> In-Reply-To: <2a7894eb0803220016m2b20b042x54456da9ec260043@mail.gmail.com> References: <2a7894eb0803220016m2b20b042x54456da9ec260043@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Murray Stokely" <murray@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080322094225.5bcdd5f5>