Specs

Political Structure

The CMS should capture the political structure of the party, including the hierarchy of places like state, zone, parliamentary constituency etc., members at each level and the leadership.

CMS will have one webpage for every place in the political hierarchy. As of now, the required levels are:

• Nation
• Region
• State
• Zone
• Loksabha ConstituencyDistrict
• Assembly Constituency
• Ward
• Polling Center
• Polling Booth

The system should be flexible enough to add more levels if there is a need. For eg, in Kerala, there is an intermediate level between the Assembly Constituency and the Ward - it is called Panchayat.

Volunteers

Volunteers can added to the system in 2 ways.

1. An admin can explicitly add a volunteer to the system.
2. A volunteer can self register, but needs to be approved to become part of the system.

Volunteers can be added only at Polling Booth OR Polling Center levels. If a volunteer has a Voter ID, then he/she will be associated with the Polling Booth he belongs to. If the volunteer does not have a Voter ID, then his address will be used to associate him with the nearest Polling Center. Whether or not a new member can be added to a level is determined by some admin setting as it is not a good idea to hardcode levels in the code. For now, assume that members can be added at any level.

Add Member

Here is a mockup of the add-member form.

If the Voter ID field is provided, it should be used to identify polling booth of the volunteer and should be associated with that polling booth. See VoterDB page for more details.

The location field should use google places autocomplete and the coordinates should be used to identify the polling center, in the case that Voter ID is absent.

At least one of Voter ID or Location needs to be mandatorily specified. If both are specified, the Voter ID takes precedence to perform the primary association.

There is system that provides location info from coordinates, but that provide resolution only up to loksabha constituencies. It need to be extended to support polling booth resolution. see Maps-Component for more details.

Who can add a member will be decided by the permission system, which is outlined below. For now, assume that anyone can add members. It'll be fixed once the permission system is built.

Applying to volunteer

The CMS should allow people to signup to volunteer. The application to volunteer involves 3 steps:

1. Authenticating the person using facebook/google.

2. Filling the volunteer application.

3. Confirmation

Once a person applies to volunteer, the application data sits in a database table and will later be reviewed by admins, who can activate the volunteer. This information needs to show up on the dashboard of the person in charge of approving volunteers at the lowest level above the polling booth / polling center the volunteer is associated with. In other words, if the only committee above the polling booth is the district committee, then a member of the district committee will activate the volunteer. We will also need a mechanism for escalation - if the request for approval of volunteer remains with a district person for say more than a week, then the request will get escalated to the state level member.

Committees

Each place can have one or more committees. Each committee is comprised of some members, each with a role. For example, there could be a Political Action Committee at every state with 'Convener', 'Co-conventer' roles in every loksabha constituency.

Typically the national level, or state level decides what all committees should be present at each level below it and what roles each committee should have.

The CMS should provide interface to define structure of committees for levels below it and also setting committees at that level.

Permission System

For now, We'll only have 2 permissions: read and write. Every permission is tied to a place and that applies to all places in its subtree. If a person has read permission on a district, he'll be able to see all information available at all assembly constituencies, all polling booths below it. Similarly, if a person has write permission at an assembly constituency, he'll be able to perform any actions that modifies something anywhere below that place.

Permission are defined by the committee roles. For example, here is a committee and roles.

Mission Vistaar Interim State Committee

• Convenor (read,write)
• Jt. Convenor (read,write)
• Secretary (read,write)
• Treasurer (read,write)
• Political Activist* (read)
• Organization Builder* (read)
• Support Team Manager* (read)

* indicates that there could be multiple people with that role.

To be able to do any write operation for the first time, we need to have at least one user with write permission. This is especially required for bootstrapping. This will be done by specifying ADMIN_USERS setting in the application settings.

ADMIN_USERS = "[email protected],[email protected]"

The people specified here will write permission at all places (or the top-level).

We may come up with a fine-grained permission system later, but this will be good enough for now.

Audit Trials

The CMS should maintain audit trails of everything that is changing in the system.