On Wed, Feb 10, 2010 at 3:13 AM, xor <xor at gmx.li> wrote: > Hi, > > I have the feeling that I have sorted out the score-calculation issues with > WoT so WoT is basically almost finished, there is only some pre-release > refactoring left to do. > > Because we want to get out WoT ASAP (due to FlogHelper needing it) and it > will be marked as final, not beta, on the plugins page I have thought a bit > about the effects of the release: > > We will have to mention that applications which use WoT are FlogHelper and > Freetalk. IF we mention Freetalk, hundreds of people will try it out. > > Because we will have a message-purge of Freetalk when leaving the beta phase > (this was always said in a big red box on the Freetalk web interface so > please do not complain) we should do the purge ASAP so that not too many > messages are lost. Right now there is not much content on Freetalk and the > useful content has been added to the bugtracker already so purging is still > okay. > > However, if we purge after having released WoT on the plugins page then we > will piss hundreds of people off probably. > > So my conclusion is that it would be very very good to release WoT and > Freetalk together (and purge the message base before). Because I have > delayed the release of WoT over and over again to fix critical issues I'm > aware of the fact that I cannot demand a large delay yet once again. > So my goal is to get Freetalk done ASAP so we can deploy it as "beta" > together with WoT. > > I have found a solution for being able to do this. Lets first consider what > prevented me from voting for deployment as soon as WoT is done: > Two things: Pending structural database changes and the lack of the ability > of specifying board descriptions. > The issues are crucial because: > > - The database changes are needed for stability. They are maximal 1-2 days > of work so they are not the problem. > - Because we will purge the messages anyway it is necessary to provide a > very clean list of default boards after that. The default boards are very > important because newbies need a good starting point of interesting content. > And one of the core issues with non-moderated forums on Freenet is that > people tend to use bad board names, bad board categories and creating > zillions of multiple boards for the same topic. So the default boards should > be good for the first time usage experience. And they should also have > proper descriptions. Descriptions should be implemented as a voting > mechanism though: If you have not specified your own description, the > description which the most people have specified should be displayed. This > is rather a larger piece of work to implement so my conclusion was that I > cannot demand that WoT deployment is postponed until I'm done with it. > > So to come back to what I wanted to say: The solution for this problem is a > rather nasty hack but it will be acceptable: I will just hardcode a list of > descriptions for the default boards, and nevertheless add a "Edit > description" button to the web interface and explain that editing is not yet > possible but will be implemented soon. > > I guess most users will be fine with that and it allows me to get Freetalk > done within the next few days so we can ship it together with WoT and > officially start telling people that we are out of the testing phase of > Freetalk in which messages could be lost. So people can actually start using > it and be sure that their messages will be readable by future versions. > > Now does that sound like a good deal? =)
First, I'm very much in favor of this proposal. I continue to believe that the highest priority with WoT is getting to the point where you're willing to make the DB reset and doing that. This approach to board descriptions sounds fine to me. (I think distributed WoT-based voting is a really interesting idea that we should definitely tackle one day. However, I think it's even harder to get right than the WoT score calculation. But then, I'm not known for my optimism on such things :) ) The one change I would suggest is that it's bad UI to have a clickable "edit" button that you only tell the user is non-functional after they click. Instead, make the button / link present but unclickable (grayed out, crossed out, whatever), with a tooltip saying the feature is coming. Second, I don't think the score algorithm issues are sorted out. Please see the new testMalicious2() test case that tests for resistance to multiple known, identified, colluding malicious identities. (Detailed thoughts in reply to your mail on the subject.) However, even given this, I think you should delay fixing the score algorithm and do what's needed to get past the DB reset. If you want to continue working on the score algorithm first, though, I'm happy to continue helping, but I'm still not optimistic about an easy fix. Evan Daniel
