[Systers-dev] GSoC Students - Please post weekly updates to Systers-dev!!

[Yian Shang]

Hi everyone,

Heh, looks like I also forgot, sorry! In any case, I've posted a blog post
about my progress here:
http://movicont.nfshost.com/blog/mailman-archives-ui-update:

> I've written out some code to demonstrate several of the use cases for the
> archives UI. The use cases can be seen on the Systers wiki, and the two I
> was focusing on were


   - Generating an index of conversations (and not just individual messages)
   with information for users
   - Displaying all messages within a conversation on the same page rather
   than on separate pages

I started out tracing bin/arch's source to see where the key functions were,
> and I noticed that HyperArchive and its parent class pipermail.T were where
> the majority of the archive generation took place. Thus, hoping not to
> modify HyperArchive for the worse, I created a subclass of HyperArchive
> (currently called HyperHyperArchive, will likely be changed to a more
> descriptive name later) and reimplemented/created the needed functions
> (here's the patch <http://movicont.nfshost.com/patch>). There is a hack
> involving Article.finished_update_article that I need to fix after I comb
> through the code more, but it works for now.



I sorted the conversations with most recently replied to first, and while I
> was working on it, I realized that the sort order might've been clearer if
> the meta-data on each conversation could show those last message dates.
> Thus, the format I generated looks more like a table with the subject line,
> date, and email address. I've put the archive I generated up<http://movicont.nfshost.com/June-2010/conversations.html> for
> demo purposes.



There has also been some discussion about choosing the appropriate subject
> line to display, since the subject can change with each message in the
> conversation. I ended up showing the first message's subject because I
> thought the first post usually drives the conversation and thus is most
> relevant. Some caveats: there might be an entirely different subtopic
> developing after a message with a different subject, though I'm not sure how
> to address that at this point.



In the user survey that was put out, I remember from the data that some
> users wanted more readable urls. Since the string after + and before @ in
> the thread email is supposed to be unique, I used that as the filename for
> each conversation, which lead to more readable urls like
> .../June-2010/reap.html <http://movicont.nfshost.com/June-2010/reap.html>
>  or .../June-2010/running.html<http://movicont.nfshost.com/June-2010/running.html>
> .



Users also want to be able to easily scan the page for the data they want.
> Thus, the conversations generated have contrasted meta data (gray) and
> message body areas (white) for easier scanning.

Individual message-linking is retained in order to allow users to highlight
> a specific message in the conversation. Each of the individual messages can
> be linked to with a bookmark in the html file<http://movicont.nfshost.com/June-2010/reap.html#3>,
> for which I used the sequence-id of the article. This unfortunately has the
> problem of not always being permanent when the archives are regenerated, so
> I'm looking into fixing it.



I am currently working on going through the code and integrating it better
> with the current archive generator. I will also be working on generating
> more permanent urls, which is something users had requested (I thought it
> might be useful to have the mailed out messages come attached with something
> along the lines of "here's the permanent link to the message in the
> archives")


On Thu, Jun 24, 2010 at 3:25 PM, Anna Granudd <anna.granudd at gmail.com>wrote:

> Hi,
> sorry for not posting earlier - now that you Jennifer mention it  I realize
> I should have posted long ago.
>
> As for my work, last week I finished a simple version of the (Django)
> models
> for Systers (basically containing the UI DB for Systers). After that, the
> rest-client got updated and I had to try and make my now "old" models run
> with the new client (which mostly resulted in finding a few bugs in the
> updated client but also a few name changes which made it necessary to
> update
> the models as well). I emailed my mentor about the bugs and he'll fix it
> globally (it's in his code) and so far I only added the fixes locally. It
> took me a few days though to make the models work again. It seems it might
> take a while though until the client gets stable but Barry suggested us to
> propose a merge for integrating it with core Mailman 3.0 so this will be
> done soon which hopefully will result in less changes. Finally, today I
> started writing unit tests for the models (although these can not yet be
> found on Launchpad since I want them to work more or less without errors
> before adding them to revision control). Apart from these, most of my work
> can be found in a separate branch on Launchpad.
>
> Thanks,
> Anna
>
>
> On Thu, Jun 24, 2010 at 11:21 PM, Jennifer Redman <jenred at gmail.com>
> wrote:
>
> > ...In the meantime (and ongoing) -- I'd still like to see weekly updates
> > posted
> > to the mailing list!  If you are blogging go ahead and post a link to the
> > blog post.
> >
> > Please plan on posting updates by Friday evening of each week.
> >
>
>
> To unsubscribe from this conversation, send email to <
> systers-dev+systersdev4+unsubscribe at systers.org<systers-dev%2Bsystersdev4%2Bunsubscribe at systers.org>>
> or visit <
> http://systers.org/mailman/options/systers-dev?override=134&preference=0>
> To contribute to this conversation, use your mailer's reply-all or
> reply-group command or send your message to
> systers-dev+systersdev4 at systers.org<systers-dev%2Bsystersdev4 at systers.org>
> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> >
> To unsubscribe entirely from systers-dev, send email to <
> systers-dev-request at systers.org> with subject unsubscribe.
>