connotea-code-devel

[Connotea-code-devel] development questions

[Andrew S. <as...@gn...>]

Hello,

=20

I've been lurking on both the connotea mailing lists for a while now and
I thought I'd pose a basic question...  Is there a public plan for
future connotea development?  I think it's great that the code is open
source, but it appears that coding is still being primarily done by
Nature and NeoReality folks (not sure if the latest enhancements are
posted to sourceforge though).  Is there a desire to open up the
development team to include other developers who want to see connotea
mature faster?  I've been helping to explore thesis project ideas for a
couple bioinformatics masters students, and collaborating on connotea
may be an interesting prospect. =20

=20

And on another note, does anyone have a good feeling for the reasons why
connotea is not being used more?  Of course, I'm asking this question
not knowing anything about usage statistics, only that I don't know
anyone personally (myself included) that uses it in production.  My
reason?  What someone referred to as Buggotea
(http://www.nodalpoint.org/2007/03/30/so_connotea_or_citeulike), which
really hinders the social aspect of the site. =20

=20

Any thoughts appreciated...

=20

Cheers,

-andrew

Re: [Connotea-code-devel] development questions

[Martin F. <ma...@ne...>]

Hi Andrew,

Thanks for posting two great questions.

Andrew Su wrote:
> I’ve been lurking on both the connotea mailing lists for a while now and 
> I thought I’d pose a basic question…  Is there a public plan for future 
> connotea development?  I think it’s great that the code is open source, 
> but it appears that coding is still being primarily done by Nature and 
> NeoReality folks (not sure if the latest enhancements are posted to 
> sourceforge though).  Is there a desire to open up the development team 
> to include other developers who want to see connotea mature faster? 
>  I’ve been helping to explore thesis project ideas for a couple 
> bioinformatics masters students, and collaborating on connotea may be an 
> interesting prospect.  

I'd say if you look over the majority of open source projects, the 
participation of outsiders beyond the original founding members is 
always a bit thin, and even in some successful projects consists mostly 
of infrequent bursts of work to produce specific patches rather than 
bona fide ongoing development. So it's not uncommon.

Add to that the fact that Connotea Code is not small and requires 
understanding of a handful of dependencies like mod_perl and memcached.

I'm still optimistic that Connotea Code can and will pick up some 
outside contributions to the core code, but I suspect they will come 
from academic institutions (as you allude).

I'm happy to say we've just successfully dumped CVS in favour of Darcs 
and that is working out great. This, I think, strategically supports 
coder participation, because Darcs is one of the new generation of 
*distributed* version control systems. What we're working on now is 
cleaning up our internal repository with the goal of having an open 
source release soon and toying with the idea of making the Darcs 
repository public to make it less necessary to make official releases.

What I suggest to anyone looking to get interested with Connotea Code is 
to look first at the well-demarcated points in the code - the Web API, 
which is external and lets you talk to connotea.org from the language of 
your choice, and internally in the main Perl code, the citation source 
module "API" and the import module "API", which are points in the 
codebase where it was deliberately intended that programmers from 
different groups would contribute. Something in that realm would be an 
ideal test project to get you started.

> And on another note, does anyone have a good feeling for the reasons why 
> connotea is not being used more?  Of course, I’m asking this question 
> not knowing anything about usage statistics, only that I don’t know 
> anyone personally (myself included) that uses it in production.  My 
> reason?  What someone referred to as Buggotea 
> (http://www.nodalpoint.org/2007/03/30/so_connotea_or_citeulike), which 
> really hinders the social aspect of the site. 

Ian and I just spoke on the phone a couple hours ago about this. It is 
now high on our priority list.

The merits of multi-URI bookmarks notwithstanding, I'm not sure it 
actually detracts from the number of users of Connotea; it doesn't feel 
like a big enough reason.

Are you perhaps muddling the concept of who might have not heard of 
Connotea yet (or even the social bookmarking phenomenon in general) with 
who might have tried Connotea and chosen to leave it because of a 
specific property of the service?

I agree that evangelism is necessary, and Connotea probably can't be a 
del.icio.us or digg.com because it strives to serve scientists, so 
unless the "anyone" in your sentence consists of scientists I would not 
expect it to hold a high percentage of users.

As for people not liking some property of the service, we do know about 
a couple issues (and the issue you mention is one of them), but if I may 
offer you a countering anecdotal report, it only seems to be on the 
radar of a minority percentage of our users and even then not enough to 
abandon the service if they otherwise like it.

If I may make a heretical observation ;-) some people do try social 
bookmarking and then sort of lose interest as well. I'd suggest this 
group is larger than those who leave because of, say, the URI-centric 
issue. Social bookmarking is an interesting development of technology 
that like everything else will take a few years to flourish and has to 
go through the normal growth phase. (Or am I wrong?)

Cheers,
Martin

Re: [Connotea-code-devel] development questions

[Andrew S. <as...@gn...>]

Martin,

Thanks for your informative reply.  Clearly lots of information.  Let me =
cherry-pick two points for a follow-up.

> I agree that evangelism is necessary, and Connotea probably can't be a
> del.icio.us or digg.com because it strives to serve scientists, so
> unless the "anyone" in your sentence consists of scientists I would =
not
> expect it to hold a high percentage of users.

Yeah, my mental calculations had already normalized for the size of the =
scientific community...  ;)  But agreed on all your points (that many =
users do use it despite current limitations, that scientists in general =
are slow to the social bookmarking bandwagon, etc.).   So then I =
especially agree with you that evangelism is an important piece of =
getting the word out (and hence increasing the value of the =
application).  In science, there is no higher evangelism than a =
scientific publication, so what is the plan there?  I think a scientific =
publication that demonstrates the incredible value of social bookmarking =
in the scientific literature would go a long way to introducing people =
to the concept and building a user base. =20

But what is needed to demonstrate scientific value?  I think an =
important piece of that is actually the multi-URI bookmarks.  Suppose, =
for example, I stumble on a gene that I haven't studied before ('akt' =
for example) and I want to get up to speed as quickly as possible.  If I =
search 'akt' in connotea, I get back 215 references, the vast majority =
of which were only tagged by a single user.  So this is good in that it =
tells me that *someone* found these articles useful (a far cry less than =
the 13218 from Pubmed), but still not as useful as non-scientific =
searches at delicious, where the number of tags is a rough estimate of =
importance.  But at least part of the problem is the multi-URI issue.  =
If within that list of 215 references, you text search for "Rhinovirus =
Activates Interleukin-8 Expression...", you see that both sundog and =
saumen tagged this article.  As a connotea user, I would like to =
highlight this article as having twice the importance of most, but =
connotea doesn't recognize that they are the same article.

In summary, I sort of view connotea now as an online bookmarking system, =
but not quite yet a social bookmarking system.  And in my na=EFve view, =
I think solving the multi-URI issue will lead to better =
importance-by-voting, in turn leading to more scientific value, leading =
to a bigger community, leading to better importance-by-voting, ...  And, =
of course, a cool publication in there would help jump-start things too.

> What I suggest to anyone looking to get interested with Connotea Code =
is
> to look first at the well-demarcated points in the code - the Web API,
> which is external and lets you talk to connotea.org from the language =
of
> your choice, and internally in the main Perl code, the citation source
> module "API" and the import module "API", which are points in the
> codebase where it was deliberately intended that programmers from
> different groups would contribute. Something in that realm would be an
> ideal test project to get you started.

Yeah, I saw the Web API and think it's obviously very cool.  Very =
Web2.0, mashup-friendly, etc.  But having said that, I see the tools =
utilizing the Web API (http://www.connotea.org/wiki/ConnoteaTools) as =
bells and whistles, while there are still some meaty things to be done =
with the core application.  For example, how many of the feature =
requests (http://www.connotea.org/wiki/RequestedFeatures) or bug reports =
(http://www.connotea.org/wiki/PossibleProblems) could/should be =
addressed through the web API?  (Not a rhetorical question...)

Obviously it's easy for the peanut gallery to inundate you with =
suggestions from the outside.  But my question boils down to this -- is =
there a structure (and a desire by current developers) by which outside =
developers can aid the effort?  Specifically on issues which you =
(current developers) or we (bioinformatics community) deem to be =
critical?

Cheers,
-andrew

Re: [Connotea-code-devel] development questions

[Martin F. <ma...@ne...>]

Hi Andrew,

Your point about the weighting of articles in regards to the multi-URI 
problem is well taken.

> Yeah, I saw the Web API and think it's obviously very cool.  Very Web2.0, mashup-friendly, etc.  But having said that, I see the tools utilizing the Web API (http://www.connotea.org/wiki/ConnoteaTools) as bells and whistles, while there are still some meaty things to be done with the core application.  For example, how many of the feature requests (http://www.connotea.org/wiki/RequestedFeatures) or bug reports (http://www.connotea.org/wiki/PossibleProblems) could/should be addressed through the web API?  (Not a rhetorical question...)

Well, no, not many of those ones. But to be fair the requested features 
list probably errs on the side of listing everything that could be done 
and not just what *will* be done (but then also partly because 
priorities change and we might change our mind and come back to it).

> Obviously it's easy for the peanut gallery to inundate you with suggestions from the outside.  But my question boils down to this -- is there a structure (and a desire by current developers) by which outside developers can aid the effort?  Specifically on issues which you (current developers) or we (bioinformatics community) deem to be critical?

To answer your question literally, the list here is the best form of 
organization for outside developers to initiate offers to build things, 
and we certainly set it up in the hopes of attracting outside participation.

Unfortunately the formal bug tracker software is private (Nature internal).

Ian Mulvany is the manager at Nature that sets our priorities and I'm 
sure he will have something to say on this general issue.

If you or your students were to work on a sizable project, which wasn't 
just for your own purposes (i.e. for a local codebase running your own 
site), then it would make sense for Ian to be involved in helping you 
select the task, and then me to be involved in engineering decisions.

We'd be excited for masters students to do thesis projects with Connotea 
or Connotea Code - if the only deciding factor was that we needed a bit 
more public structure, then I think you will find us interested in the 
suggestions.

Martin