Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[bioontology-support] Bootstrapping the dev environment from scratch

Ray Fergerson ray.fergerson at stanford.edu
Fri Nov 21 16:34:46 PST 2014


Mark,



While the items that you list below seem reasonable we simply do not have 
the resources to spend to create and maintain this kind of system. In fact 
the VM was originally created because we could not maintain this sort of 
information and most of our users wanted to just run the system, not modify 
it. The system consists of close to a dozen types of dependent data stores 
and it is quite complicated to get it going.



While our current documentation is limited, we do have examples of people 
going in and creating significant additions to the system already with what 
we have. Our bias is that the number of people who really want to do so is 
limited, though.

Of course we do not know for sure that more people really want to contribute 
and would do so if it were easier. We certainly have not been overwhelmed 
with requests and complaints in this area.



To summarize, though our external developer documentation is limited, it is 
unlikely to become more extensive in the near future.



Ray



From: bioontology-support 
[mailto:bioontology-support-bounces at lists.stanford.edu] On Behalf Of Mark 
Gerard
Sent: Monday, November 17, 2014 5:03 AM
To: support at bioontology.org
Subject: Re: [bioontology-support] Bootstrapping the dev environment from 
scratch



Ray,



Thank you for the reply -



In my opinion, if an FOSS project is to attract contributions from external 
developers, it should (at-least) have three things in place to facilitate 
contributions and the integration of (those) contributions into the 
repository.



1. An externally accessible *up to date* issue tracker



The reason you want this to be externally accessible is to allow anyone with 
interest in the project to take a peek at the available issues and gauge how 
much they can contribute. This also has the added advantage of improving 
project visibility, in that interested parties can quickly discover what to 
work on in the project, without having to ask the current maintainers -



The absence of an issue tracker poses some challenges:

- Interested contributors have to track down issues all by themselves (like 
you asked me to “clicked around” - too much work if you ask me)

- Heightens the possibility of collisions (different developers working on 
the same issues) due to lack of visibility

- Harms project visibility (the project is opaque from my POV)

- A lot of emails and questions about project status, documentation, how-to 
etc (because the available documentation is fragmented and not consolidated 
in one place).



An issue tracker also helps with scoping of milestones, tracking of issue 
progress and references (when was a given bug fixed or feature implemented). 
This subsequently makes planning/tracking releases easier in the long run.



2. Quick installation/start up guide



This is to enable developers quickly check out the project and try it to see 
if it is worth contributing to. The Java community nailed this with maven’s 
convention over configuration approach in that some FOSS projects take 3 
steps, for the dev to get started:

- checkout the code base

- mvn clean install

- mvn deploy



I personally prefer to set up the project, because then I know what I am 
dealing with as opposed to downloading a pre-configured VM!



3. A transparent process of integrating external contributions



This is key because you do not want anyone submitting code to the repository 
but you want to foster a contribution based model loosely modelled after 
meritocracy. This means that the most active and interested people in the 
project are recognized and entrusted with custody of the code base, so that 
they can review and integrate contributions from new members and/or external 
contributors.



The advantages of this are:

- The project can manage code quality easily (not everyone commits)

- Recognizes top contributors based on merit

- Implicitly sets in a motion a training scheme based off a patch submission 
system

- Anyone can submit a patch (but not all patches will be committed).



I might be mistaken or I might not be looking in the right places, but I don’t 
see these in place. I believe the absence of a contribution infrastructure 
is a major put off for individual contributors to the project.



It would be nice to have these three things set up because as bio-portal 
gains more attention, you are going to get more contributors asking the same 
questions as I am doing. I am willing to spend time helping to set these up, 
if I can get help from the existing developers.



Mark



On Nov 14, 2014, at 1:59 AM, Ray Fergerson <ray.fergerson at stanford.edu> 
wrote:



Mark,

Paul has put together some documentation to get you up and going. We had
some laying around but it wasn't really useful for external folks. The new
documentation can be found off of:

https://github.com/ncbo/ontologies_api

We don't make our issue tracker system open but, even if we opened it, it
probably would not help too much. Few items are described in enough detail
for anyone else to actually understand what is needed.

Here are two idea for coming up with something to do:

- Monitor the mailing lists for requests. For example, just this morning
someone asked about a third party plugin for MS word that allows people to
insert a reference to a BioPortal class into a word document. This plugin
is broken because it uses an old version of the API. Revising this to use
the new API would be a straightforward task that would be very useful.
This would be a great first think to work on.

- Play with BioPortal. I am sure that if you clicked around in BioPortal
for an hour you could come up with a half a dozen ideas for things that
would make it better, at least for some users. I suggest only that you
contact us to find out if your ideas are already being worked on. For
example, we have a revision of the ontology browse page underway already
and this should be out in a month or so.

Ray

-----Original Message-----
From: bioontology-support
[mailto:bioontology-support-bounces at lists.stanford.edu] On Behalf Of Mark
Gerard
Sent: Friday, November 7, 2014 1:27 AM
To: support at bioontology.org
Subject: [bioontology-support] Bootstrapping the dev environment from
scratch

Hei folks,

I am interested in contributing to bio-portal in individual capacity. I
have been talking with Ray about this and he has signed me up with the
various services where I can get started with setting up the dev
environments.

I have two questions:
1. Is there a ticket list I can look at to get acquainted with the
roadmap?
2. Is there documentation explaining how I can set up the dev environment
from scratch apart from the VM? I am using a mac running OS Yosemite.

Thank you

Mark
_______________________________________________
bioontology-support mailing list
bioontology-support at lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/bioontology-support



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/bioontology-support/attachments/20141121/b22b2c17/attachment-0001.html>


More information about the bioontology-support mailing list