General design

[stevenyaga]

• Define a participation process template to lay down the different forms/steps involved
• Define a participation process which is an instance of a template
• Attach resources/materials to a process e.g resource maps
• Define tools to be used for participation e.g venn diagrams, daily schedule, ranking etc. These tools should be added as part of a process template and consequently as part of the process instance
• For each step in the process, define a logistics and preparation part that explains how the step is to be performed. See https://herproject.org/files/toolkits/HERproject-Participatory-Learning.pdf
• For each step add a list of questions to be asked
• For resource mapping, allow participants to pick points on the map. Allow drawing objects on the map and give these locations labels. A section must be specifically marked as "resource map" in which case a mapping interface will be presented
• Allow defining of facilitation/assessment matrix. A matrix should be linked to a process template
• Allow printing of a process

Why design each step separately?

Each step in a process is loosely coupled from other steps. This has the following advantages:

• User roles and permissions can be attached to each step separately from other steps
• Dashboards can be developed against data collected for each step
• Reports can be generated independently against each step
• A step can be moved between different stages of a process
• Data can be collected independently. Think of a step that takes months before completion e.g tender evaluations and budgeting. This means that data for other steps can be collected thus removing dependencies unless such dependencies are hard-wired into a process

References

• https://herproject.org/files/toolkits/HERproject-Participatory-Learning.pdf

[stevenyaga]

Justification for using Frappe framework

1. Meta-data driven. It is used to generate database tables, design forms and configure a lot of features. Meta-data is stored in a Model which is known as DocType in Frappe
2. Form designer is highly advanced supporting all types of fields including map and file attachment3.
3. The visual query designer allowing non-techies to create custom reports including group by, pivoting and aggregations
4. Development of API is highly versatile allowing integration with other data stores/sources
5. Comprehensive audit trail ensures that data modifications is tracked at field level
6. Inbuilt Insights module allowing business intelligence operations like trends, charts and dashboards
7. Users, Roles and Permissions. Frappe comes with User and Role management out of the box. A User is someone who can login to the system and perform authorized actions like creating, updating or deleting records. A Role is a mapping of DocTypes and actions allowed to perform on it.
8. Responsive design inbuilt allowing rendering on all device sizes
9. Support for different views for a Doctype i.e Listview, Kanban, Calendar and Report. Listview supports paging, filtering, sorting and bulk editing records. The Form View used for editing records also supports file attachments, PDF format, comments, email, etc. The Report Builder supports adding columns, grouping, filtering, sorting and saving it as a configuration. CalendarView allows visualizing dated records in form of a calendar
10. Email: Frappe supports sending and receiving emails, which can also be linked to individual documents
11. Printing. Frappe supports generating PDF print formats based on Jinja Templates. It also comes with a drag-and-drop Print Format Builder.
12. Python, JS and MariaDB. Frappe Framework uses Python for the backend. It comes with a simple yet powerful ORM as an abstraction over CRUD operations. The default database is MariaDB. Postgres support is in beta. The front-end is an SPA built using Javascript (jQuery).
13. Background Jobs. Frappe also supports background job queuing based on Python RQ.
14. Multi Tenant. Supports multi-tenancy out of the box. It means you can spin up multiple instances of apps with separate databases on the same codebase.

[stevenyaga]

Features

The platform will have different tools that the public can engage in. Examples are:

1. Surveys. Drill down and capture quantifiable data using a variety of question types and rich media
2. Q&A. Allow people to ask questions
3. Stories. Allow community to listen, understand, and relate to others
4. Discussion forums. Moderated interactive spaces for considered discussion and dialogue by community
5. Guestbook i.e simple online feedback without dialogue
6. Quick polls. Allow you to ask a single question and capture snapshot of sentiment or priorities
7. Submissions. When formal responses are required. Accept, review and post submissions from your community
8. Mapper. Interactive mapper to gather comments, surveys and photos on a map with a simple pin drop
9. Ideas/brainstorming. Post notes for brainstorming in the early or divergent stages of community engagement.

See https://demonstration.engagementhq.com/ and https://youtu.be/F_IhLa54w2U and https://conversation.auspost.com.au/national

• https://github.com/netchampfaris/frappe-ui-starter/tree/main

• Auspost puts up a discussion every two weeks and allows people to discuss it. Once it is done, they close the conversation and start a new one

[stevenyaga]

A separate front end will be built that will allow users to interact with the system.

[stevenyaga]

More features

• Have a concept of an Engagement. An engagement will represent any engagement that a county involves itself in. PCRA 2023 is a separate project from PCRA 2024 for instance. An engagement should have a status (open/closed) to determine when to collect feedback or not. Allow publishing of an engagement. Each engagement will be linked to an admin level to enable higher aggregation at PIU level
• Have a concept of Engagement Type to enable reporting by such
• Have a concept of Engagement Template to define different steps (doctypes) to be undertaken. Instances of an Engagement will inherit a template
• Define a concept of action plans that is as a result of completion of an engagement. These action plans will be approved/adopted etc

[stevenyaga]

Finer implementation

To achieve versatility in the tool, the logic is designed as follows:

1. The system has a concept of Engagement. An engagement refers to any undertaking by the county. This might involve single-sided communication e.g where users are submitting complaints, or it may be bi-directional for example in cases of participatory budgeting
2. An engagement can have multiple engagement types. For instance, we can have form-based data collection while at the same time accepting comments from the public around the same engagement. The support for this multiple engagement types allows the system to aggregate all manner of data around an engagement. E.g a county can have a view of data collected using forms while at the same time have access to comments/feedback received from the public during a budgeting cycle
3. Data capture will be done primarily via the frontend. The backend still has support for the same
4. Action plans are developed around an engagement. See #16 . This will enable linking of interventions/actions to a specific engagement. Members of the public will be able to track status of their proposals

[stevenyaga]

More links:

• https://wikis.ec.europa.eu/pages/viewpage.action?pageId=50109057
• https://www.epa.gov/international-cooperation/public-participation-guide-tools-generate-and-obtain-public-input
• https://countytoolkit.devolution.go.ke/sites/default/files/resources/Template%20for%20reporting%20on%20PP%20in%20CIDP.pdf