On 3/4/13 10:15 AM, Cory Johns wrote: > Stefano, > > +1 on removing the enabled flag now that it's a tool. I agree that it is > superfluous. >
+1 > 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 Yep. Having it in bootstrap.py for new Allura instances, and requiring a little manual work for existing Allura instances is fine I think. > 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 >>>> <>< >>>> >>> >> > -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
