incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Van Steenburgh <tvansteenbu...@gmail.com>
Subject Re: User stats and organizations
Date Mon, 25 Feb 2013 21:10:09 GMT
Stefano & Simone, 

Hey guys, I started doing some more testing on user stats today, and I have a couple questions.

1. Do you mind if I force-push a rebased-to-master copy of si/5453 to origin? Your branch
is quite out-of-date relative to master, and when I rebased it there were several merge conflicts
and other cleanup necessary to get the code running. You're welcome to do the rebase yourself
of course, but if you're not comfortable with that I'd be happy to do it.

2. I noticed that all the user stats links are rooted at /userstats. I think it would be preferable
to have the stats tool installed in the user projects instead. So, the url would end up looking
something like "/u/admin1/stats". What do you guys think of that idea?
 
Tim Van Steenburgh


On Saturday, February 23, 2013 at 9:07 AM, Stefano Invernizzi wrote:

> Yes, we fixed the issue in our code, it should be ok now. At the moment,
> when I try to run all the tests I get some errors from other packages. I
> tried to fix them, but I don't know how to do that, since they come from
> modules and packages dealing with repositories, and they are unrelated to
> our code.
> Thank you very much!
> Stefano
> 
> 
> 
> 2013/2/21 Tim Van Steenburgh <tvansteenburgh@gmail.com (mailto:tvansteenburgh@gmail.com)>
> 
> > Hi Simone and Stefano,
> > 
> > I pulled your si/5453 branch today to do some more testing. I rebased it
> > against master and kicked off the tests (`./run_tests` in the project root)
> > and got some failures. If you guys can get those fixed up and pushed back,
> > I'll try to wrap up the testing.
> > 
> > Thanks!
> > 
> > Tim Van Steenburgh
> > 
> > 
> > On Monday, February 18, 2013 at 2:26 PM, Simone Gatti wrote:
> > 
> > > Dear Cory,
> > > what Dave said is correct, we refer to user stats.
> > > I'm sorry for this ambiguity, that we didn't noticed before your comment.
> > > We welcome your *feedback on user stats*, since we have not yet received
> > > many comments yet.
> > > 
> > > Simone
> > > 
> > > 
> > > 2013/2/18 Dave Brondsema <dave@brondsema.net (mailto: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 (mailto:stefano.invernizzi88@gmail.com)
(mailto:
> > > > > 
> > > > 
> > > > 
> > > 
> > 
> > stefano.invernizzi88@gmail.com (mailto: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 (mailto:dave@brondsema.net)
> > > > http://www.brondsema.net : personal
> > > > http://www.splike.com : programming
> > > > <><
> > > > 
> > > 
> > 
> > 
> 
> 
> 



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