search

kbase / project_guides

This repo contains documents and guides that describe project principles, how-to docs, etc.
MIT License
7 stars 33 forks source link

Create ThirdPartyDevelopmentProtocol.md #38

Closed aparkin closed 9 years ago

aparkin commented 9 years ago

This document outlines the near term approach to queuing up and serving third party developers who expect to integrate new methods and data into KBase.

aparkin commented 9 years ago

We should add the messaging about helping projects talk to DOE about their milestones and our schedule and roadmap and our process for prioritization. We should add pointers to the key principles documents and the necessity of our open source license. We should add pointers to policy on services accessing outside resources.

mlhenderson commented 9 years ago

We'll have to flesh this out more, but it is important to have this document available even in a draft form.

dangunter commented 9 years ago

+1. Would suggest we put placeholders to these things needed, put issues for fixing them in JIRA, and merge this in.

aparkin commented 9 years ago

Ok. Who does that? :)

mlhenderson commented 9 years ago

I would suggest we merge this draft to have the document actually in the repo for reference, then edit with placeholders so that others can help out. Shane can assign each of the production team leads to review the doc and make sure their area is well covered regarding what info we need. The Exec should also review.

fperez commented 9 years ago

Excellent, thanks. Leaving the PR open for a couple of days so others can comment.

benbowen commented 9 years ago

Can this be called "development guidelines" instead of "third party development guidelines"? In other words, remove distinctions between internal and external. In my opinion, KBase developers should be subject to the same requirements as KBase users for adding new services and data. This document should be meant to facilitate the success of both parties.

I'm uncomfortable with the idea that others get to decide on the impact of a new method/data. If a KBase user feels its worth adding: as long as it doesn't break anything, why not let it in? Make it easy to take it out or sandbox new methods/data if there are concerns. Review is a major pain anyway. Better would be to automate it with testing. How can a panel of reviewers decide on the potential impact of a new method? Is there an equation for this?

fperez commented 9 years ago

@aparkin, I can merge this puppy for further edits, but since we just got some feedback from @benbowen, it would be good to address it first. I have my own thoughts, but will let you pitch in first from your perspective.

danielolson5 commented 9 years ago

+1

We may want to separate this into a general developer protocol, and protocol for integration with other existing projects/systems. This seems to currently try to address both.

Dan

On Apr 29, 2015, at 5:47 PM, Ben Bowen notifications@github.com wrote:

Can this be called "development guidelines" instead of "third party development guidelines"? In other words, remove distinctions between internal and external. In my opinion, KBase developers should be subject to the same requirements as KBase users for adding new services and data. This document should be meant to facilitate the success of both parties.

I'm uncomfortable with the idea that others get to decide on the impact of a new method/data. If a KBase user feels its worth adding: as long as it doesn't break anything, why not let it in? Make it easy to take it out or sandbox new methods/data if there are concerns. Review is a major pain anyway. Better would be to automate it with testing. How can a panel of reviewers decide on the potential impact of a new method? Is there an equation for this?

— Reply to this email directly or view it on GitHub.

aparkin commented 9 years ago

@benbowen

Well... one day I hope we can go your direction but right now:

1) We need a compliance test for open source, not using unblessed external resources etc. 2) The lift for knowing if we can even execute the software is pretty high right now. 3) Data integration is still and will remain to be a bit of a bear and we should review. 4) We really need not to litter our system with more poorly working, poorly documented tools. 5) We do need agreement on maintenance

It is true-- this is the same for internal and external developers. My point is we are not yet a drop-in system and there are fiduciary responsibilities we have for quality assessment, maintenance and resource costs, etc.

I don't mind making the bar for acceptance based on perceived impact low... but...

aparkin commented 9 years ago

Fernando-- should we merge this?

fperez commented 9 years ago

Yes, I think so. We can iterate further more easily on top of it merged. Doing so now. Thanks everyone for the feedback and discussion!!