Quantcast
Viewing all articles
Browse latest Browse all 49206

Decisionmaking API & Consensus Module

Edit, October 2 -- This proposal has been passed along to the Knight Foundation for consideration -- http://drupal.org/node/316407 End Edit

Proposal Overview

This project aims to create and implement a flexible framework for group decisionmaking processes. The proposal has two technical components and one implementation component.

Technical components

  1. Creation of a Decisionmaking API, an abstracted, pluggable system designed to manage any form of group decisionmaking.
  2. Implement the Decisionmaking API by creating a Consensus module, which will model the formal consensus decisionmaking process.

Implementation component

  1. Formal consensus is an intricate process, and is difficult to successfully execute even when in person. Inculcating software with best practices developed over decades by consensus practitioners will require its own, unique testbed. We'll provide such a testbed, and report back to Knight/the community on it.

Background

Group decisionmaking is a crucial part of everyday life. It encompasses everything from the informal consensus folks often use when figuring out where to go for lunch with friends from work, all the way to complex multi-stage voting processes used by governmental legislative bodies to decide on the passage of legislation. In fact, these two examples effectively illustrate the range of activities that 'group decisionmaking' spans. Although it's far easier to see differences than similarities between, say, picking a sandwich shop and passing legislation to cap & reduce carbon emissions, the two do share a core commonality: in both cases, relevant stakeholders are consulted and weigh in on a decision, with the understanding being that once a given decision is reached, action will follow.

Communities of all shapes and sizes rely on their decisionmaking processes to hold themselves together - or at least the healthy ones do. Drupal, being the social publishing system that it is, is quite capable of producing sites and circumstances where tools for running, recording, and finalizing group decisions would be very beneficial. Ironically, the KDI proposal process itself could benefit from this tools in this proposal...

EXAMPLE: the KDI Proposal Process

Please bear in mind that this is NOT intended as a criticism of the process itself! If anything, it recognizes that the KDI process does quite well with the available software, but that the software could do much more to support that process.

Using the tools currently available, anyone can initiate the KDI process by posting a proposal. Once a proposal has posted, all community members are allowed to comment on (a qualitative response) and rate the proposal using fivestar (a quantitative response). If and when the comments (subjectively) and the ratings (more objectively), along with the discussions in IRC indicate that there is a critical mass of interest in the proposal, the proposal is made official, and preparation begins to send the application along to Knight directly.

There are a number of specific areas within the KDI process that the Decisionmaking API could likely improve upon:

  1. At present, only one node is associated with the proposal & entire process. This makes it difficult to clearly delineate between multiple lines of discussion related to the proposal (comment threading helps, but isn't ideal), especially at the database level (if we wanted to use Views to show a discussion summary, for example). Such a lack of clarity is not necessarily a huge problem while the discussion is happening; however, it makes archival records of the decision more difficult to organize & follow.

    Though current plans for the Decisionmaking API will have it continuing to use a single node as the 'master' for the discussion, it will utilize a number of techniques (largely rooted in modules like Taxonomy, Views, Panels) that will organize each decision into a user experience that is intuitive with respect to the flow & structure of the decision itself.

  2. While a standard process has been devised for the review of these proposals, that process is not directly reflected in the software. For example, the current process has no internal notion that a discussion on IRC has been conducted. The conventional solution - uploading a log of the conversation - is one possible solution, although a smarter subsystem could theoretically be written that extends Druplicon's normal behavior.
  3. There is no clearly defined process for making amendments to the original proposal. Sure, the original node author could make changes, and that may be adequate for some forms of decisionmaking, but it'd be great if we could leverage the node revision system to provide a full catalogue of node history revisions. The capacity is already there, after all...
  4. We can make fivestar-based ratings of the original proposal, but what about sub-components of the proposal, if they exist? Either we come up with some other, probably not-in-drupal way of doing it, or a new node has to be created. Nodereference would probably be the best bet for associating the new node with the original, but I genuinely don't know how flexible nodereference is when it comes to defining different 'types' of nodereferences (as would be useful for this case), as well as how directly accessible metadata about those references would be.
  5. Once a decision has officially been made, we have a few options for actually indicating that in the proposal thread: a) just do nothing; leave the thread open. b) close the thread. c) either a) or b), but also post a final comment indicating the status of the proposal. None of these are really optimal, though, for a few reasons:
    1. People viewing the thread should be immediately able to discern the status of the proposal without having to scroll around or look anywhere else.
    2. Simply because a proposal has been passed along doesn't necessarily mean that discussion about the proposal should stop - but it does mean that it should probably change. Amendments to the original proposal, for example, probably ought not be possible once a decision has been made.

Other potential Drupal beneficiaries

KDI isn't the only part of the Drupal community that could benefit from this project, of course. The Drupal Association regularly engages in group decisionmaking processes, but the lack of a unified framework for those decisions means they often have to hunt for outside tools. In the Association session at Szeged, the speakers also indicated a need for keeping better records of their decisions.

The d.o redesign might also benefit: whereas most decisions in the Drupal world that affect thousands of Drupal users retain resolveability because they ultimately come down to the technical judgment of a few people with commit access, the redesign process presents a very different challenge. Because there's no one "right" answer for the redesign, the process is really about the inclusion of as many people and ideas as possible, as inclusivity generates both buy-in and better ideas. Of course, inclusivity is far easier said than done - but a decisionmaking API could make notable strides towards achieving it. Unfortunately, this project probably won't be ready in time to assist the redesign process much - but the current redesign process is also unlikely to be the Drupal community's last mass-input decision.

Beyond Drupal, and Consensus

The DA and redesign are big-name examples, but they're hardly the only things that stand to benefit from a structured decisionmaking system, particularly if we look beyond the Drupal community's borders. Any organization that has to a) make decisions as a group with any frequency, b) could benefit from having those decisions recorded for future reference, posterity, or transparency could implement and benefit from a structured decisionmaking process. Everything from a small community to an enormous company potentially falls into that group.

The second technical component - a Consensus module that implements the Decisionmaking API - is integral to the proposal in a number of respects. First, without a full-blown implementation of the API, other developers interested in implementing the API won't have examples to work from. Moreover, the API won't be useful until some implementations of it have been written. Second, formal consensus is especially good at achieving decisions in groups without explicit hierarchies. Given how much interaction over the internet is ad-hoc (and therefore not explicitly hierarchical), consensus may be able to help fill an important gap.

If you're not familiar with formal consensus process, these links ought to help. Checking them out is especially recommended if you're accustomed to informal consensus. If you know 'consensus' but have never heard of 'formal consensus,' then you're accustomed to informal consensus, so that means you =)

Participants accustomed to straight voting models often find formal consensus odd or confusing at first - and if participants find the process challenging, that says a lot about how difficult it will be to model adequately in code. I (sdboyer/Sam Boyer) am a fairly experienced consensus practitioner - I've pretty much lived by it as an activist for the past four years - but my experience can do little more than ensure our initial attempts are in the right ballpark. If we really want to nail formal consensus, as well as the underlying Decisionmaking API, it'll take UX testing - preferably from people who have experience with in-person consensus already. Fortunately, we're in a position to provide just such a testbed.

If this proposal goes through to the Knight Foundation, then it will officially be made by a registered U.S. non-profit (501(c)3) called Global Justice, an umbrella organization that houses three student-run, student-led campaigns - the Student Global AIDS Campaign, Student Campaign for Child Survival, and Student Trade Justice Campaign. Because all of the campaigns utilize consensus at various levels in their organizing, we're the ideal testbed: thousands of people with consensus experience, but no Drupal experience.

Note: My personal affiliation is with that last campaign, and yes, I'm completely redoing all those websites in Drupal - if you've ever heard me refer to my "mega-site," this is it.

================================================================

How does your proposal meet the stated goals of the Knight Drupal Initiative program?: 

This proposal's strongest connection to KDI goals is its potential to "enable powerful agents of transformation in [peoples'] communities." Group decisionmaking is deeply intertwined with democracy and human society writ large; for this basic reason, a decisionmaking tool has the potential to transform communities on two levels:

Internally
When deployed into community groups, this tool has the potential to enhance that community's decisionmaking processes on a number of levels:

  1. Speed/Efficiency: Because many low-level tasks related to the decision are handled by the toolset, the decisionmaking process is likely to proceed along faster than it might have otherwise. Moreover, since best practices can be solidified into code, the toolset could help inexperienced organizers to move quickly through the stages of any given decision.
  2. Inclusivity: In a self-organizing community, achieving wide inclusivity on a decision is the only way for that decision to gain legitimacy. While people asking people to participate will always be more effective than computers asking people for the same input, there are considerable logistical burdens involved in building buy-in that could be eased by software.
  3. Transparency: Ask any community organizer: good note-takers are a rarity, and good systems for organizing those notes once taken are even less common. Consequently, the fact that the proposed tools are all self-documenting and self-organizing lends serious transformational potential to this toolset: groups are guaranteed a 'paper trail' that corresponds exactly to the original decision, as well as an intelligible organization that makes following that paper trail later feasible.
  4. Clarity: for community organizations, group decisionmaking is largely about lending legitimacy to actions. Legitimacy, in turn, is inherently linked to a clear, accepted process that drove those decisions. Utilizing software to progress through a decision means that there is absolute clarity about the process leading to the decision.

Externally
There is an inverse relationship between the number of people participating in a decision and the extent and nature of their participation. Historically, civic participation tends to get reduced to simple, one-dimensional actions (like voting) when the number of participants is even moderately large. This is at least somewhat due to feasibility constraints: for U.S. Presidential races, it's completely infeasible to sit 300 million people down together and have individual chats.

However, the internet (and this proposed toolset in particular) does open up the potential for more articulated & nuanced participation than simple voting. Think, for a moment, of reducing civic participation to voting as a structured technique for clarifying a cacophony of opinions into an actionable outcome; at a very basic level, the proposed toolset shares this exact same goal. That common goal means, at least in theory, that effective implementations of this software could lead to more robust methods of civic participation, which in turn would enhance the capacity of communities to participate in an articulate public dialogue.

================================================================

How long will your project take to complete?: 

We'll be approaching this in three phases, one for each component, using the following approximate schedule. Note that these are preliminary estimates, and comments/suggestions are most welcome.

  • Phase 1: Week 1 through Week 8
  • Phase 2: Week 4 through Week 14
  • Phase 3: Week 12 through Week 24~32

Phase 1: Approximately eight weeks from start to an operational beta. If we write the Decisionmaking API well and properly abstracted the first time around, then we won't need to do much except bugfixes once it hits beta. We'll only really know that it's got everything it needs once there's a working beta of Consensus as well, however.

Phase 2: Work on the Consensus implementation is likely to really start a few weeks after Phase 1 begins, and last around ten weeks. The overlap period with Phase 1 will be where we really ensure that the API does everything we need it to. Once we've tapered off work on the API, the focus will be on filling out the features of the module itself.

Phase 3: We'll begin Phase 3 a couple weeks before closing out Phase 2, under the "strike while the iron is hot" philosophy: assuming that the Consensus module is stable enough for some basic usage, releasing it for feedback from our testbed of folks while the programmers are still in a creative mental state about it.

Phase 3 itself will last four to six months, as we anticipate that there will be notable changes in both the modules themselves (according to the feedback we get) and our users' perceptions of it (as they become more used to it), and it will be worthwhile to keep the reports coming throughout the process.

================================================================

How will you implement and distribute your project?: 

The proposal has three phases: creation of the Decisionmaking API, implementing that API to model formal consensus decisionmaking, then providing the tool to a large group of individuals experienced with consensus decisionmaking and improving the tool based on their feedback.

Phase 1 - Decisionmaking API

Given the level of abstraction, flexibility and range of use cases that the Decisionmaking API will need to support, we face a not-inconsiderable risk of code bloat and significant memory usage, not to mention the potential for an incomprehensible API. Keeping these caveats in mind, the core engine will adhere to several major principles:

  1. It will utilize a plugin-based architecture for as much of its functionality as possible; that architecture will require the creation of separate .inc files to minimize loaded code. Though the engine's internal implementation of this system will change in Drupal 7 (the registry will obviate the need for internal handling), the basic benefit of well-organized plugin code will not be lost.
  2. Though the engine itself will remain abstracted, it will provide a number of low-level API tools for modules implementing the Decisionmaking API to make their job easier.
  3. Somewhat along the lines of #2, the Decisionmaking module will come packaged with a number of already-written plugins that provide simple functionality for certain aspects of a decision, and may also integrate with existing Drupal & non-Drupal functionality - things like Organic groups (for determining participants in a decision), Advanced Poll, VotingAPI, etc.
  4. It will be written largely in OO for three basic reasons: the benefits of polymorphism, far easier unit testing, and because it will integrate more cleanly with Handlers when that day comes. Also, the API will utilize various features of SPL, so expect a requirement of at least PHP 5.1.3. Given the additional need for good date handling, PHP 5.2 will probably be the final requirement.
  5. Once the API stabilizes, the code will be heavily documented via docblocks - we'll aim for core standards - and online API documentation will be provided to ease the task of learning the API for other developers.

Depending on the difficulty/time required, the module package may also come with some fully-written decision implementations that handle simpler, common decisionmaking processes such as simple majority voting.

From the first line of code written onwards, the Decisionmaking API will use the Drupal CVS repository to track its development per standard Drupal practice. It will be developed simultaneously for Drupal 5 and 6.

Phase 2 - Formal Consensus

Formal consensus is among the more complex of group decisionmaking models because it places at least as much emphasis on the process as it does on the outcome. Outcomes are easier to model because they are often straightforward and mathematical (e.g., simple majority succeeds when more than 50% of the participants vote yes), and once concluded can usually be expressed in a boolean (the decision either succeeded or failed). Process, particularly with formal consensus, is often concerned with less quantifiable factors, such as having all participants genuinely consider the opinions of other participants (especially those that differ). As such, some non-quantifiables cannot enforced by anything we can code; in such cases, our goal will instead be to design the tools, flow, and general user experience in a manner conducive to realizing those process-related factors.

There are also different models for formal consensus, which further complicates things. Ideally, we'll write the consensus module in such a way that the components that differ across the models will be pluggable, so it'll be easy to pick one model or another. Mix-and-matching may even eventually be possible. However, our initial implementation will probably aim at implementing just one model, then expanding later.

As with the Decisionmaking API, the Formal Consensus module will live in the Drupal CVS repository from inception. It will be developed simultaneously for Drupal 5 and 6.

Phase 3 - Implementation (the testbed)

The public face of the implementation phase will be regular reports, both to Knight and to the Drupal community, about what we're learning from our students as they interact with the software and make suggestions for improvements. There will be (at least) one non-programmer from Global Justice responsible for making these regular reports; s/he will also be more generally available for discussion related to the progress of the project.

Given that consensus isn't the only decisionmaking option we'd like to make available to our students, it may also be feasible to add other implementations of the Decisionmaking API to our site and roll in some UX testing to our general reports. We're not likely to do direct, intensive UX testing beyond spring of 2009 though (that's a wild estimate), so there is a time element involved.

We also intend to pull together an advisory board of folks with various different sorts of group decisionmaking experience and knowledge. Ideally, that group will incorporate a range spanning academic game theorists and mathematicians to trained consensus practitioners and community organizers.

================================================================

What is your total budget estimate and how much funding are you requesting: 

These are very preliminary estimates, and we'd welcome feedback/suggestions.

  • $60,000 for 600 programmer hours at $100/hr. This hourage should be sufficient for all the necessary programmer hours up through a final, stable release.
  • $20,000 for 800 organizer hours at $25/hr. Organizers' responsibilities will mostly be about adoption and reporting:
    • Adoption: Our organizers will need to encourage adoption of not only the decisionmaking system, but the whole new website system that it's embedded in. Some 'adoption' hours will go towards training the organizers, but the remainder will be the organizers facilitating our students' transition to the new systems
    • Reporting: Although we'll be using proper bug trackers, the organizers are likely to receive the brunt of the qualitative feedback which will partially constitute the Phase 3 reports. Consequently, they'll play a large role in composing the regular reports.
  • $7,500 for 100 statistician hours at $75/hr. A statistician will be greatly helpful in fleshing out the quantitative aspects of our Phase 3 reports.

Total Funding Request: $87,500

================================================================


Viewing all articles
Browse latest Browse all 49206

Trending Articles