Date: Sat, 22 Mar 2008 14:26:35 -0700 From: "Murray Stokely" <murray@stokely.org> To: "Alexander Leidinger" <netchild@freebsd.org> Cc: freebsd-doc@freebsd.org Subject: Re: Please Review: design doc for Project Ideas web application Message-ID: <2a7894eb0803221426t10f552a7n1a1f84b8f31956f6@mail.gmail.com> In-Reply-To: <20080322094225.5bcdd5f5@deskjail> References: <2a7894eb0803220016m2b20b042x54456da9ec260043@mail.gmail.com> <20080322094225.5bcdd5f5@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 22, 2008 at 1:42 AM, Alexander Leidinger <netchild@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a7894eb0803221426t10f552a7n1a1f84b8f31956f6>