advertise size of community on homepage

[chadwhitacre]

Change the top tagline to include something like: 1,895 people are giving to 3,652 other people in the world.

Reticketed from #634 per @MikeFair.

[zbynekwinkler]

Is this still relevant? I'd like to start helping and this seems like sufficiently little thing to get started :)

[chadwhitacre]

@zwn Thanks for jumping in! Be sure to check out the info here:

https://www.gittip.com/for/contributors/

If you're comfortable with IRC then it'd be great to chat in #gittip on Freenode.

To dive in here the next step would be a sketch (paper or pixels) of how we would implement this info on the homepage.

[zbynekwinkler]

I tried to look around the codebase first before discussing the homepage pixels. I think I know how the simplates are setup and I think the info I need is in the 'tips' table. Where/how should I setup the variables for the counts to have it accessible in base.html? Should I create another inbound hook?

[chadwhitacre]

IRC

[chadwhitacre]

@zwn

• We have the skeleton of an aspen-vim but it's not really viable yet. The workaround right now is to manually do :set filetype=python or :set filetype=html as needed. You can set a default for the .spt extension with au BufNewFile,BufRead *.spt setlocal filetype=python in your .vimrc (the default in my Vim for .spt is SNOBOL4, which I at least am willing to override).
• The homepage is at www/index.html.spt. What's the reason to modify templates/base.html?
• If you do need to add more simplate globals, you can do so in the add_stuff hook in configure-aspen.py.

[zbynekwinkler]

Thanks @whit537. I see I was getting ahead of myself while trying to understand the structure of the code base. While diving in it appeared to me it'd be nice to have this info on all pages and not just on the homepage. Could it fit in nicely somewhere close to "DISTRIBUTED GENIUS GRANTS"? That would give it some kind of a measure, like what is meant by that. If it should be only on the homepage then maybe under "Inspiring Generosity" could be the right place. But having seen gittip just about two weeks ago for the first time I am not sure. How it should be decided? I am willing to implement it (I'll go and try my first fork on github :)).

[chadwhitacre]

@zwn The metric I usually use is "{number of weekly active} active users exchanging {dollar volume} per week." For this ticket, let's replace the "Distributed genius grants" text with that. Weekly active users should include anyone who either gave or received money on Gittip during the last payday. This means getting start/end timestamps from the paydays table and using those bounds to query the transfers table.

[chadwhitacre]

See #858 for tightening up the computation of weekly active users on the stats page.

[zbynekwinkler]

I have gone over the payday.py really quickly to learn about the start/end timestamps. While there I've noticed nparticipants and transfer_volume in the paydays table. Isn't it exactly what we want? AFAIU it is the number of participants in a given payday and the amount of money transferred.

[chadwhitacre]

transfer_volume: yes. nparticipants: no, because it includes people who didn't actually give or receive that week but were nonetheless registered on the site and considered as part of the payday loops. Maybe we want to modify payday.py to record nactive?

[zbynekwinkler]

I like the idea of having the number precomputed in payday. I am looking at mark_participant which updates nparticipants = nparticipants + 1 even if the participant has no successful tips. What about setting nactive to the number of participants with non-zero pending right before the payday is closed and the pending cleared? Well, that would ignore users that tip exactly as much as they receive, so no. So querying the transfers table then seems to be the only way. Maybe something like

SELECT count(DISTINCT *) FROM (
    SELECT tipper FROM transfers WHERE 'timestamp' >= ts_start
        UNION
    SELECT tippee FROM transfers WHERE 'timestamp' >= ts_start
    ) AS foo

run right before the self.end()? If this would be the solution, how would I go about testing it? I see test_billing_payday.py but I am not sure where/if to put it there.

Now I see similar queries mentioned in #219 - I should have looked at the stats page earlier :).

[chadwhitacre]

@zwn I like this approach, too. Active users include people who give or receive or both. It's not enough to just count givers. At the same time, we don't want to double-count people who both give and receive. It might be best to do this as a query after the fact, but that goes against the grain of how we're tallying the other aggregates now: incrementing as we loop. Can we increment as we loop in this case?

[zbynekwinkler]

I was trying to find a place but I do not know how not to double-count. Actually the way the code is structured now I do not know how to count the receivers, no matter the double counting. It lends itself to counting the givers easily. I guess we would need a flag for each user to keep track who has been counted already which looks kind of silly since the info can be easily queried later without additional code.

I would go with precomputing the number of active users with the query above and storing that with the payday in nactive. If we display this info on each page hit it helps it is O(1) and will not grow with the number of transfers. At the same time the query is somewhat self documenting.

[zbynekwinkler]

Well, I tried to create something. I am not that familiar with a proper github work flow but hopefully my commit should be accessible for review. Feel free to comment on the code and/or the work flow. https://github.com/zwn/www.gittip.com/commit/4cd3ae20389f82620c7180f243aed588a6fa531b

[chadwhitacre]

One consideration is that during payday the charts page includes the current payday as it is running. We're not showing active users there yet but I'd like to (instead of just givers). If we don't compute active users inline during payday then we'll want to tweak the charts to only include paydays that have completed. That's okay, I guess.

[zbynekwinkler]

I can tweak the stats and charts next.

[chadwhitacre]