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

Mark Gerard kata.mapkon at
Mon Nov 17 05:03:29 PST 2014


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.


> On Nov 14, 2014, at 1:59 AM, Ray Fergerson <ray.fergerson at> 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:
> 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] On Behalf Of Mark
> Gerard
> Sent: Friday, November 7, 2014 1:27 AM
> To: support at
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bioontology-support mailing list