Naming Conflict
by Yaakov Nemoy
Hey List,
We have a minor naming conflict issue to figure out. There is another package in Fedora called ekg. I want to figure out what we should call the python package.
We have a few choices, i think
1) python-ekg (makes sense compared to virtualenv which also includes scripts)
2) ekg-scanner (since it's really an application and not necessarily a library)
3) rename ekg to something else
4) other
I'm leaning heavily towards door #1, but i just wanted to hear if there are any good reasons why we don't want to do that.
Please advise
-Yaakov
15 years
Git repo changes
by Yaakov Nemoy
Hey all,
Instead of using separate folders for each version requiring the
developer to have all three versions in front of him, i've split it up
into three branches.
The folder that was v1 is not so surprisingly the branch v1
The folder that was v2 is even less surprisingly the branch v2
The folder that was v3 is to possibly mild amazement the branch master.
If you were carrying any patches on top of the old directory structure
and are wondering how they can be rebased/merged, you'll see the
wonders of git. Git's tracked each and every move, so any patch that
applies to '/v3/something' will automatically be migrated to apply on
top of '/something' without any intervention.
Max, this is also a topic i plan on bringing up at my Git presentation
at FudCon, so you are now going to regret having me do it in German
;).
-Yaakov
15 years
Status Report 2009.04.28 early afternoon
by Yaakov Nemoy
Hey List,
I've added a setup.py and spec file to the repository. In a little bit, i'll hopefully have a review request setup, so we can see it show up in Fedora 11 updates in a couple of weeks. This will let people get a chance to play around with it more easily.
-Yaakov
15 years
Status 2009.04.22 Early Morning
by Yaakov Nemoy
Hey List,
I've spent most of my evening slowly putting together a temporary fix for the issues we're having with RH's mailman. We're gonna do what v2 did, stripping info straight from the website. It's slow, but it's theoretically the same as reading an mbox if we switch the code later down the road.
One thing that's vindicated my design is that i've done it in relatively few fundamental changes of code. Mostly, it's just about putting the pegs in the right holes. I've come across a bit of trouble because there is some escaped HTML on these web pages that needs to be unescaped. I haven't been able to find an agreeable solution yet, and i don't want to write my own. So i'm gonna sleep on it.
If anyone wants broken code, i can do a commit when i wake up.
-Yaakov
15 years
Status 2009.04.27 mid afternoon
by Yaakov Nemoy
Hey All,
Just some notes, i have the RHMailman class working, and i've done a bit of reorganizing to master to divide up the code a bit more cleanly.
I think a UML diagram might be a good idea to keep track of all the data attributes. Otherwise it could get messy.
It also has zero error checking in it, which means we need to test it to shake out the bugs.
Next up i think is making a setuptools setup.py for it, so we can install it and make a package.
-Yaakov
15 years
R Graph Gallery
by Michael DeHaan
I was talking to Michael Tiemann today and he mentioned the R Graph
gallery contained lots of rather interesting visualizations.
Perhaps something to look at: http://addictedtor.free.fr/graphiques/
Some are relatively out there, but if anything it may give some ideas,
though perhaps R would be interesting to use to run some other
statistical analyses on our data.
--Michael
15 years, 1 month
[lhospo@gmail.com: Important: Get Your Proposals Submitted to the GSoC 2009 site sooner rather than later]
by Karsten Wade
Just a note that we want to turn our GSoC proposal discussion in to an
actual application ASAP, based on whatever we have so far.
This URL was missing from the original email:
[0] http://socghop.appspot.com/document/show/program/google/gsoc2009/userguid...
----- Forwarded message from "LH (Leslie Hawthorn)" <lhospo(a)gmail.com> -----
Date: Wed, 1 Apr 2009 12:11:22 -0700 (PDT)
Subject: Important: Get Your Proposals Submitted to the GSoC 2009 site sooner rather than later
From: "LH (Leslie Hawthorn)" <lhospo(a)gmail.com>
To: Google Summer of Code Announce <google-summer-of-code-announce(a)googlegroups.com>
X-BeenThere: google-summer-of-code-announce(a)googlegroups.com
Hello everyone,
Right now, we have about 2x the students registered on http://socghop.appspot.com
as we do # of proposals submitted. We are also hearing from our
mentors that they are reviewing many more proposals than have been
submitted via the GSoC 2009 site, e.g. "We have six applications
turned in but are reviewing another 20 or so in our forums."
I realize that many organizations are working with students to refine
their proposal ideas on their mailing lists, wikis, etc. However, a
proposal on a wiki, mailing list, etc. does not constitute an actual
application for the program; the proposal must be submitted to the
GSoC 2009 site. While doing review and refinement outside of
http://socghop.appspot.com is a useful exercise, it doesn't allow us
to accurately gauge the number of student proposals we're receiving
for GSoC 2009.
Please help us get an accurate sense of how many proposals will be
submitted for GSoC 2009 by submitting your student proposals to the
GSoC 2009 site *now*. It is fine if the proposal is still in draft
format. You are welcome to link to the wiki page, mailing list thread,
forum topic, etc. where your proposal is under discussion and
refinement as part of the proposal submission process.[0]
Finally, many organizations are asking for student to submit patches
as part of the application process. Don't let the patch requirement
stop you from submitting your proposal. The proposal may not be
reviewed until the patch is submitted, but we've given mentors ~2
weeks to review proposals (and any patches they request) after the
application deadline, which is this Friday, 3rd April at 19:00 UTC.
Cheers,
LH
PS - Contrary to all rumors you may hear, we have not extended the
application deadline. Further, don't assume that the deadline will be
extended.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Summer of Code Announce" group.
To post to this group, send email to google-summer-of-code-announce(a)googlegroups.com
To unsubscribe from this group, send email to google-summer-of-code-announce+unsubscribe(a)googlegroups.com
For more options, visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en
-~----------~----~----~----~------~----~------~--~---
----- End forwarded message -----
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
15 years, 1 month
Concrete idea for my GSoC project
by Wojtek Walczak
Hi all,
I have prepared a description of my possible ekg-GSoC project.
Here it goes:
I. Network of connections between members based on reply pairs.
AIM: Create a network of connections based on the structure of replies
and number of mails sent by every user in each reply-pair and answer
such questions as:
- who is the core member of the community (by e-mail domain)?
Add pie chart.
- who is a regular member of the community (by e-mail domain)?
Add pie chart.
- who is a temporary (passive) member of the community
(by e-mail domain)? Add pie chart.
- how many members are in each group? Add pie chart.
- what is the level of exclusiveness and responsiveness for the mailing
list?
- are the temporary (passive) members active, i.e. do they speak with
each other? (the assumption is: temporary members are there to ask
some specific questions, receive the answer and go to their work;
they are not participating in discussions other than the discussions
they started; and if they do - if there are pairs of replies:
temp_member <-> temp_member - then it means that they are also
participating in general discussion, which should be a good prognosis
for particular community)
In case of weekly/monthly/quarterly slices show the dynamics:
- are the core/regular/temporary groups changing?
Are the numbers changing? Are the e-mail domains changing?
Is the density in groups changing? Present these results
on line charts.
II. Basic data structure
Connecting users on the basis of the structure of replies has two
dimensions:
- number of connections to other users
- number of mails sent by each user to any other user
In terms of data structures it could look like this:
X = {
emailX: {
'emailY': number_of_replies,
'emailZ': number_of_replies,
...
},
emailY: {
'emailX': number_of_replies,
'emailZ': number_of_replies,
...
},
...
}
A number of connections for user 'emailY' is:
number_of_connections = len(X['emailY'])
A number of all the messages sent by user 'emailY' is:
number_of_all_emails_sent = sum(d['emailY'].values())
A number of e-mails sent by user 'emailY' to user 'emailX' is:
number_of_emails_sent_to_emailX = X['emailY']['emailX']
I consider filling such a data structure with actual data as one
of the mile stones of my project. But, let's assume that it is filled,
so we can continue our thought experiment.
III. Core members, regular members and temporary members
Beased on these two indicators - number of connections and number
of mails sent by each user - we are able to create a network of
connections between members and thus distinguish core
members group, which should be defined as a group of people for
which the numbers of connections and mails sent are highest.
Moreover, we are able to distinguish regular users and temporary
users. Temporary users come and go, their networks of connections
are weak and they are not exchanging too many mails. Regular
users are somewhere between.
When it comes to deciding who is in the core group and who is not,
a number of algorithms may be used.
A possible algorithm could look like this:
1. Count the average number of connections for all users.
New variable: avg_number_of_connections.
In terms of proposed data structure:
connections_sum = 0
for user in X:
connections += len(user[X])
avg_number_of_connections = connections / float(len(X))
2. Count the average number of mails sent for all users:
New variable: avg_number_of_mails_sent.
In terms of proposed data structure:
mails_sent = 0
for user in X:
mails_sent += sum(X[user].values())
avg_number_of_mails_sent = mails_sent / float(len(X))
3. Create three levels of participation for both parameters
(number of connections and number of mails sent):
a) high (core members):
- 'number_of_connections' is rated as high if it is
75% or more of the average;
New variable: num_of_connections_high:
num_of_connections_high = avg_number_of_connections * 0.75
- 'number_of_mails_sent' is rated as high if it is
75% or more of the average;
New variable: num_of_mails_sent_high:
num_of_mails_sent_high = avg_numer_of_mails_sent * 0.75
b) low (temporary members):
- 'number_of_connections' is rated as low if it is
25% or less than the average;
New variable: num_of_connections_low:
num_of_connections_low = avg_number_of_connections * 0.25
- 'number_of_mails_sent' is rated as low if it is
25% or less than the average;
New variable: num_of_mails_sent_low:
num_of_mails_sent_low = avg_numer_of_mails_sent * 0.25
c) medium (regular members):
- 'number_of_connections' is rated as medium if it is
found in range between 25% and 75% of the average;
- 'number_of_mails_sent' is rated as medium if it is
found in range between 25% and 75% of the average;
4. Go through the dictionary of users and assign them to one of three
groups: core_members, regular_members, temp_members.
If both variables - number_of_connections and number_of_mails_sent -
for particular user are higher than 75% of the average (vide:
num_of_connections_high and num_of_mails_sent_high), then the user
is a member of the core group.
If both variables - number_of_connections and number_of_mails_sent -
for particular user are lower than 25% of the average (vide:
num_of_connections_low and num_of_mails_sent_low), then the user
is a member of the temporary members group.
Else: assign the user to regular members group.
Now that we have our data structure filled and we have identified
the groups of members, we are able to answer a few of the questions
stated at the beginning, but some of them still remain unanswered.
It is because the idea of counting the level of exclusiveness,
responsiveness and temporary users participation requires better
explanation (and more code).
IV. Exclusiveness, responsiveness, and temporary users participation levels
Possible reply pairs (reverses included):
a) core member <-> core member (CC)
b) regular member <-> regular member (RR)
c) temporary member <-> temporary member (TT)
d) code member <-> temporary member (CT)
e) code member <-> regular member (CR)
f) regular member <-> temporary member (RT)
Given our lists of core/regular/temporary members and our basic
data structure we are able to count what follows (reverses included):
CCS = sum of all CC replies
TTS = sum of all TT replies
RRS = sum of all RR replies
CTS = sum of all CT replies
CRS = sum of all CR replies
RTS = sum of all RT replies
* Level of exclusiveness: CCS / (CCS+TTS+RRS+CTS+CRS+RTS)
Level of exclusiveness indicates how often core developers speak
only with each other. Possible values: min. - 0.0 and max - 1.0.
Minimum value means that core developers don't speak with each other
at all, and maximum value means that they speak only with each other.
* Level of responsiveness: CTS / (CCS+TTS+RRS+CTS+CRS+RTS)
Level of responsiveness indicates how often core developers speak
with temporary members. Possible values: min. - 0.0 and max - 1.0.
Minimum value means that core developers don't speak with temporary
members at all, and maximum value means that core developers don't
loose any chance to speak with temporary members.
* Level of temporary users participation: TTS /
(CCS+TTS+RRS+CTS+CRS+RTS)
Level of temporary users participation indicates how often temporary
members speak with each other. Possible values: min. - 0.0 and max
- 1.0.
Minimum value means that temporary users don't speak with other
temporary
users which might mean that they came only to get the answer they need
and then go. Maximum value means that we probably have some new strong
contributors.
V. Network of connections: a graph
A bit of social networks analysis. Show a map of connections between
users including the information on how strong the ties between them
are (based on the number of mails exchanged).
OK, that's all for now, thanks for reading :-)
All your comments are greately appreciated!
--
Regards,
Wojtek Walczak,
http://tosh.pl/gminick/
15 years, 1 month