Agreement Templates - Githubissues

bryangw1 commented 9 years ago

Following the work we've done in the clause bank, I have created a separate folder for different agreement templates.

To explain this by analogy, for any given soccer team there will exist a league structure. Under the league structure there is a coach who picks the players on the team. Some individual players are better at performing certain functions than others. The coach, when picking his team may have a particular formation/structure that he likes, or knows that one particular type of structure works well against another type of structure and can pick his players accordingly.

The clause bank will function as the pool of players. The agreement templates will be the formation/structure. The coach will be the architect of the system, in charge of assembling the proper clauses and formation together.

bryangw1 commented 9 years ago

https://github.com/UMKC-Law/DataSharingAgreement/tree/master/AgreementTemplates

dazzaji commented 9 years ago

I like this.

| Sent from my iPhone | Please Forgive Typos

On Jun 30, 2015, at 11:30 AM, bryangw1 notifications@github.com wrote:

Following the work we've done in the clause bank, I have created a separate folder for different agreement templates.

To explain this by analogy, for any given soccer team there will exist a league structure. Under the league structure there is a coach who picks the players on the team. Some individual players are better at performing certain functions than others. The coach, when picking his team may have a particular formation/structure that he likes, or knows that one particular type of structure works well against another type of structure and can pick his players accordingly.

The clause bank will function as the pool of players. The agreement templates will be the formation/structure. The coach will be the architect of the system, in charge of assembling the proper clauses and formation together.

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

dazzaji commented 9 years ago

See: https://github.com/UMKC-Law/DataSharingAgreement/issues/12

A clause bank is a good way to collect clauses in a common way so they are sharable with others. Google Materials Design style "Cards" are a good way to display clauses in a simple, understandable and actionable manner. Cards are a type of "Web Component" (paper element, specifically) and these are good ways to ensure content, style and function are truly interoperable and there are broadly available tools and resources available for anybody to participate in such interoperable reuse.

If the UMKC summer class only gets so far as expressing clauses suitable for HIPAA, FERPA and other data sharing agreements in a common manner suitable for expression in cards that would be good. If you can also demo the clauses in a way that enables use of some clauses from another source that is great. Just let me know what stage you are at and we should talk about what clauses and contracts we can help you with by making some content sourced at MIT available for use by the UMKC summer class. But if you are able to compose your cards not as fancy idiosyncratic javascript but instead as standard paper material web componentized elements then that is truly perfection. That would represent the most interoperable, usable and valuable achievement in electronic contract practices today. I spent a few years chairing the ABA Business Law section group on electronic contracting practices... and speak from to much experience on that narrow eddy of the law. I recommend you take a look and work with the summer interns and volunteer team at MIT to develop your data sharing agreements using polymer web components ... and see what happens.

Details in comment to #12

HazardJ commented 9 years ago

This is very interesting. I haven't fully understood, but seems like part of an ecosystem. Will look a bit further.

Separately, Paul refactored the CommonAccord code - putting nearly all the code in a /vendor/ folder and rejiggering. I've been improving (to my lights) the interface and adding a few elements. See my.commonaccord.org, for instance. http://my.commonaccord.org/index.php?action=source&file=FoleyGRS/FCPAPolicy/Form/FCPA_01-01.md.

Also separately the link above is to a doc contributed by an expert on FCPA compliance - a significant issue in international dealings. This is part of a solution for supply chains.

HazardJ commented 9 years ago

My current iteration of Paul's refactoring is on Github at CommonAccord/Site-My, and when he and I coordinate, we can post it as a separate repo with only code - a socket for a roll-your-own site of documents. If I've understood the Polymer project correctly, it can be an alternative path for "consuming" materials. Perhaps like the browser-based rendered described at https://github.com/CommonAccord/Site-DataShare/issues/1

HazardJ commented 9 years ago

continuing above thought - or like integrations with payments systems.

dazzaji commented 9 years ago

Hi Jim .... It's not primarily about "consuming materials". Some components are materials and some (soon the large majority) are not. I'll pull a ticket to review and understand web components. It's primarily about using web components. Which are a perfect fit for CommonAccord on many levels.

dazzaji commented 9 years ago

And, done: #13

UMKC-Law / DataSharingAgreement

Agreement Templates #11