Stefano, +1 on removing the enabled flag now that it's a tool. I agree that it is superfluous.
I think what Dave was suggesting is to manually change the Users Neighborhood to include userstats and then whenever a user's profile is visited, it will cause the userstats to be installed at that time. We could also maybe create a ScriptTask to "touch" each user profile to force it to be installed if it needs to be present before a user actually visits a profile. I may be misunderstanding here, though. On Sun, Mar 3, 2013 at 4:35 AM, Stefano Invernizzi < [email protected]> wrote: > Thanks Dave for your suggestion! I modified the bootstrap.py file, so that > when the Users neighborhood is created, our tool for userstats is set as an > anchored tool, and it perfectly works. However, that way, if you do not run > the bootstrap.py, you have to manually add the tool to the anchored ones. > And this is what happens in most cases for users who don't want to > re-initialize the forge. > > I was also thinking about the setting in the .ini file to enable userstats. > I think it doesn't make sense to disable them now that stats are > implemented as a tool. By setting userstats.enable = false, the tool is > still installed for users who were using it, therefore I think it's better > to remove this option, since it would be confusing. That way, a user who > wants to install the forge without using userstats can simply avoid > installing the ForgeUserStats tool. I committed this change too, but if you > think it's better to think again about it, I'm open to different proposals. > Thanks again, > > Stefano > > > > 2013/3/2 Simone Gatti <[email protected]> > > > Dear Dave, > > I have changed the preference page in order to meet these requests. > > I created two new pages to collect data about contacts and availability. > > In the preference page, over the links, it is now indicated that these > > personal data are not compulsory. > > In this way, the preference page will no more become so long due to data > > about contacts and availability precedently inserted by the user, and the > > forms not necessary are not disclosed. > > About general personal data, I decided to leave its original form in the > > preference page, because it has fixed size and refer to general > > information, but I put an explicit indication that they are > discretionary. > > Please, let me know what do you think about these modifications. > > Thanks, > > Simone > > > > > > 2013/2/18 Dave Brondsema <[email protected]> > > > > > Cory, I think Stefano is referring to user stats, which his feature > > branch > > > starts collecting, not user profile data (gender, location, etc). > > > > > > But on the topic of user profiel data, we've had a least one > SourceForge > > > user > > > communicate to use that he/she thought the fields were required. I can > > > see how > > > this might be inferred since they're the first thing you see on the > > > /auth/prefs/ > > > form. We might consider labelling those optional, or putting them on a > > > separate > > > page from "subscriptions" and other sections on that page. > > > > > > -Dave > > > > > > > > > > > > On 2/18/13 9:55 AM, Cory Johns wrote: > > > > Stefano, > > > > > > > > Could a user simply not fill in the personal info fields they don't > > wish > > > to > > > > share? What is the value of entering that info but then not > displaying > > > it; > > > > to encourage users to enter it if only for our edification? > > > > > > > > > > > > Thanks, > > > > > > > > Cory > > > > > > > > > > > > On Sat, Feb 16, 2013 at 9:53 AM, Stefano Invernizzi < > > > > [email protected]> wrote: > > > > > > > >> Dear all, > > > >> > > > >> I recently pushed some new commits allowing a single user to hide > his > > or > > > >> her personal statistics. I and Simone implemented it since some > users > > > may > > > >> prefer not to show this data. In that case, data is still available > > for > > > >> their personal use. However, if you think we should not allow users > to > > > do > > > >> this, we can simply put it back as it was. > > > >> As usual, we hope to get some feedbacks from you about this, as well > > as > > > >> about the rest of submitted code. > > > >> It would be great for us if the code could be reviewed and, if you > > > think it > > > >> would be useful, included on the forge before we complete the thesis > > we > > > are > > > >> working on. > > > >> Thank you very much! > > > >> Stefano > > > >> > > > > > > > > > > > > -- > > > Dave Brondsema : [email protected] > > > http://www.brondsema.net : personal > > > http://www.splike.com : programming > > > <>< > > > > > > -- ==== This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
