incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Invernizzi <stefano.invernizz...@gmail.com>
Subject Re: User stats and organizations
Date Sun, 03 Mar 2013 09:35:21 GMT
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 <simone.gatti88@gmail.com>

> 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 <dave@brondsema.net>
>
> > 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 <
> > > stefano.invernizzi88@gmail.com> 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 : dave@brondsema.net
> > http://www.brondsema.net : personal
> > http://www.splike.com : programming
> >               <><
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message