BenoitTalbot / bungeni-portal

Automatically exported from code.google.com/p/bungeni-portal
0 stars 0 forks source link

Bi-cameral legislature support #714

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Some parliaments are bi-cameral, they have 2 houses.  Usually these 2 chambers 
function independently - i.e. they have indpendent sets of members of 
parliments, who present parliamentary items for discussion.  

There is some data exchange that happens between the 2 chambers - this is 
usually for the "Bills". In some countries bills are presented in one chamber, 
and can continue their lifecycle in the other chamber. 

Methodology
--------------

 * Each chamber will get a separate bungeni installation. Each of these systems will function as an indpendent - having their own set of members of parliaments and users. Additionally other parliamentary structures like - committees, political groups etc will exist in both systems as independent entities.   This is logical given that the 2 chambers function independently and have their own authority structures in terms of having their own speakers and committees.

 * Similarly each chamber will have their own document workflows - e.g. for motions bills etc.

 * In the case of the Bill we have a situation where at some point of its workflow the bill gets "sent" to the other chamber for further workflow processing. There are various ways to implement this scenario :

    1- The bill gets packaged into a format with all the information about itself and this packaged bill is placed into a "queue". The bill "package" will have all the metadata and content of the bill including information about its point of origin (i.e. the bungeni parliament sending the bill).

    2- The bungeni running at the other chamber (lets call it the receiver) -- reads the  bill package from the "queue" -- and uses the metadata and content information in the package to create a bill document in the receiver chamber instance of bungeni. Ownership of the bill is by default granted to clerk of the receiver parliament, and once the bill is created in the receiver parliament it enters the workflow of that parliament. 

    3- The origin information of a bill needs to captured somewhere by bungeni for a parliamentary item.

    4- The recieved bill may end its lifecycle in the "receiver" parliament -or- may need to be sent back to the originating parliament -- this depends upon the parliament. This will be guided by the workflow. 

    5- If the bill needs to be sent back to the "origin" parliament after processing in the "receiving" parliament, then it is packaged and placed on a "queue" (just like in step 1- ). The origin parliament reads the quueue , unpackages the bill -- and updates the existing bill in its system with the changed state of the bill, and places it in the active workflow of the origin parliament again.

  * The above method could be logically extended to any parliamentary item. 

Technical 
---------------

  * The proposed method aims to keep the coupling "loose" between the 2 parliamentary systems -- since in reality they function as independent bodies -- additionally this is in line with the principle of keeping such integration simple and flexible.

  * The "queue" can be a message queue implementation -- since the 2 bungeni systems are decoupled i.e. every bungeni has a queue which the bungeni running at the chamber is aware of and checks for postings on a periodic basis.

  * The bungeni of each chamber is aware of the "versions" and "changes" of an item -- these versions are not posted to the other system, only the publication state, metadata and content is posted.  So for example - if a bill is posted from chamber A and is recieved by chamber B - then the versions view of the bill in chamber B will not show the versions of the bill from chamber B (it could just say "bill originated from chamber A" ) . 

  * The "format" of the package needs to be decided.

  * The "origin" information for a bill / parliamentary item needs to captured somewhere -- this can mean multiple points of information - origin parliament, origin committee, origin owner, origin seconder(s). etc.

Original issue reported on code.google.com by ashok.ha...@gmail.com on 4 Jul 2011 at 8:19

GoogleCodeExporter commented 8 years ago
I think that "what to package" and "what can be changed" by the "receiving" 
parliament need to be detailed, what "type" of info.

We need to see if all info will be editable by the "receiving" parliament or 
not. E.g. the "receiving" parliament may publish the Bill i their own official 
publications, at that point the this info has to be changed, but e.g. the 
author etc. is info that may not be allowed to be changed.

An additional issue of bicameral system need to be addressed, "joint 
committee". This are committees that have members by both chambers. Usually 
just one chamber is "responsible" for these committees. 

Original comment by flavio.z...@gmail.com on 25 Jul 2011 at 1:34

GoogleCodeExporter commented 8 years ago
Closing All these issues -- As the list is being updated to match with the 
whiteboard backlog.

Original comment by ashok.ha...@gmail.com on 7 Sep 2012 at 7:57