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
- Creation of a Decisionmaking API, an abstracted, pluggable system designed to manage any form of group decisionmaking.
- Implement the Decisionmaking API by creating a Consensus module, which will model the formal consensus decisionmaking process.
Implementation component
- 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:
- 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.
- 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.
- 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...
- 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.
- 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:
- People viewing the thread should be immediately able to discern the status of the proposal without having to scroll around or look anywhere else.
- 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 =)
- Consensus decision-making (Wikipedia) <-- you want this Wikipedia page, not the general Consensus one
- Consensus Network
- On Conflict and Consensus
- Consensus Decision Making (Seeds for Change)
- Consensus Decision Making (ACT UP NY)
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.
================================================================
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:
- 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.
- 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.
- 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.
- 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.
================================================================
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.
================================================================
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:
- 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.
- 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.
- 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.
- 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.
- 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.
================================================================
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
================================================================
Comments
to put this in my tracker
to put this in my tracker and :
@todo: leave a comment why i've given this 5 stars.
notes: Coming from open source group organizer background i understand how difficult it is to reach consensus based on community input. this field is rather unpolished and this project will most definitely help introducing a new and well functioning standard to help us.
------------------
Sometimes interesting things appears on http://litwol.com
interesting stuff
in #drupal-dojo meeting today, I mentioned, and was asked to post about this module: http://drupal.org/project/decisions
might be relevant - might not ;-)
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Thanks for posting this up,
Thanks for posting this up, Mike - I hadn't seen this module before. I gave it a quick look, and I have two quick thoughts: first, it looks a little abandoned, especially if you look at the issue queue and the provided 'home page.'
Substance-wise, it looks like they're a step more abstracted than things like votingapi or poll (judging from the hooks their API documentation offers), but the most basic difference between their concept and this proposal is that they're focused on arriving at a single decision by use of a particular algorithm. The decisionmaking API's goal is to provide ways for decisions to encompass more than just any one single process (mathematical or not), as well as to record, package, and present the whole picture of that decision in a way that's easily digested. Basically, it recognizes that there's a lot more to any given group decision than the very final vote, and so tries to wrap all those different pieces up together into one, big "decision."
A consensus module would be
A consensus module would be a huge benefit to the online world. Great initiative.
This proposal needs work though. We need more specifics on what the user sees and what the admin sees, during consensus building. Basic stuff. I fear that funding a proposal in this form will lead to giant plugin based OO ball of worthlessness.
...a proposal in this form
That's quite a picture :)
So I was torn while writing the original proposal; my first draft was already 3200 words, and I ended up deciding that adding another thousand words to detail out the structure of the proposal wouldn't be prudent for the initial proposal, partially because I haven't worked out all the details yet. If this initiative is something that the community thinks ought to go forward, then I'll happily publicize and keep updated my plans for the architecture.
At this point, I've done enough planning to feel fairly confident that I have an approach which will allow for lightweight solution that need not turn into spaghetti; however, I've yet to fully step through all aspects of it. Consequently, I think that posting up everything that I have at this very moment would just be an invitation to get this thread off track, so it would be best to wait on providing specific details until I do have a more comprehensive plan. There are still some general things to be said, that are hopefully somewhat helpful:
class Consensus extends Decisionversus aclass Consensus implements Decision; that's my mind's boiled-down version of debating about how much code goes in the engine vs. how much goes in the implementation. At the end of the day, though, I'll decide on the thing that generates the least spaghetti :)There are also some personal dimensions to this that I think bear on your basic concern:
I've got a few parts to my response to the other part of your comment (re: what the user sees vs. what the admin sees). The first part is clarifications: what do you mean by 'admin' - the person who initiated the decision? The notion of an admin is itself kind of antithetical to consensus, given that a basic assumption in the consensus model is that all participants have an equal voice in the process.
Ohhh wait. Admin as in, site admin, who's configuring global settings related to how the consensus decisionmaking processes would work? Assuming that's the case, yeah...so, a quick explanation of one major component I've largely settled on may help:
When you install the Consensus process module, you won't get just one version of Consensus for everything you do, end of story. I'm currently envisioning an admin interface wherein you can define 'flavors' of Consensus, with each flavor having slightly different parameters set. Simple example: you could define a 'Long Consensus' which uses a 36-hour time period for each phase of the consensus process, and a 'Quick Consensus' which uses 4-hour time periods for those phases. 'Long Consensus' and 'Quick Consensus' then each become decision 'types' that users can choose from in picking out which method to use. These could also be defined in code so that they can be slotted in pretty much wherever you want.
There'll be a larger principle at work behind the scenes, too: basically, any decision will need to have certain configuration parameters passed to it before a new decisionmaking process can be initiated. The plugin itself won't care if that data comes from pre-saved settings in the db somewhere (i.e., from a site admin creating 'Long Consensus'), directly from code, or from some other pre-ordained source. All it'll know is that when a new decisionmaking process is fired up, if it's missing any of these necessary configuration parameters, then a form will need to be generated so that the user can set them right then and there. My hope is that this basic logic - let the user set whatever hasn't been set already - will allow for really easy, intuitive scaling fully user-configurable decisions to locked-down, pre-defined processes.
As for what the interface itself will look like, that's an enormously important question, and is a large part of the motivation for including the third phase of the proposal, which can basically be thought of as a UX component.
Thanks for the comment!
And on re-reading your post,
And on re-reading your post, and re-reading my proposal, I realize that there really aren't any specifics as to what the UI would look like. Sure, we'll need UX...but at least a general sketch is absolutely necessary.
I'll work one up tomorrow or over the weekend. I do actually have something in mind =)
Cool stuff!
As requested in IRC, this sounds awesome, and I'm hereby bookmarking this page for reading later :-P g
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
So I've gotten quite a
So I've gotten quite a number of comments from folks indicating that they like general idea put forth by this proposal, but that they haven't fully digested it yet. I'm loathe to write up MORE, since it'll only make it harder to digest. All I can think to say is: NO comment or question is too small! There's no need to wait until you've fully grokked the proposal before you post!
Thoughts on the proposal
I've seen a number of smaller projects along these lines come and go while maintaining VotingAPI -- I think the proposal is right on target in recognizing that VotingAPI and similar simple rating tools are absolutely not up to the task of gathering this kind of information.
My biggest concern is related to Moshe's earlier comments. Making Decisions covers a lot of ground, and solving it abstractly is going to be very, very difficult. I see a couple of discrete challenges:
All three of those are pretty heady stuff. I think even just givign people the tools from #1 would be a great leap forward. I'm not sure how any single API could effectively handle all three of the above challenges. Perhaps the distinct problems being tackle could be described in a little more detail, with the lines between them clarified?
Very excited to see this project proposed, by the way. Just wanting to make sure that it gets the attention and planning that it deserves.
Thanks for the comment,
Thanks for the comment, eaton - I'm just posting a quick note to say that I've seen this, and upon reading it & reflecting further on Moshe's question, I realize what's really needed here is some concrete examples. So I'll have em soon!
good questions
I think these are good questions, and I'm looking forward to seeing sdboyer's response.
Overall, I like this proposal a lot. Allowing for a variety of decision making systems within a single API is likely to be difficult, but it'd be quite essential for many potential real life applications. Consensus is probably harder than most to map into code (doing some clever proportional vote calculation in PHP is likely to be more straightforward in the end than deciding whether someone has 'blocked' a decision or not and how to manage that process), so it seems like a decent candidate - it's also very far away from what Voting API does compared to other possible implementations.
The emphasis on recording the process leading up to a decision looks pretty interesting, and again something that's not easy to do with existing tools (including pen and paper).
I'll hold off on more comments until sdboyer has had a chance to follow up.
Some concrete details!
OK - this is as clean and short as I can possibly make it. If you want a bunch more background on the context all this fits in to, see this blog post.
Quick background
Right now, our organizations are dealing with the following basic issues re: group decisionmaking:
Consensus on conference calls can, with considerable effort, be more or less achieved. But on a call with, say, 10 people, it's more common for the process to work like this:
Please do keep in mind that this is a brief description given out of context; I've intentionally left out the wider context for brevity. If you really want something like the wider context, then you need my blog post.
Nuts and bolts
With a decisionmaking system in place, however, that whole process could change drastically AND require less frustrating overhead effort from the participants. Here's what it could look like instead. Note that I originally wrote this in February, although I've modified it a bit. Assume that 'Groups' are just plain ol' OG groups.
Because this is a hefty list, a quick overview of the stages:
Now, the full process:
Whew. And even THIS isn't an entirely complete picture. Amendments to the original proposal are hugely important for many decisionmakign processes (consensus included), but I've left it out entirely as an attempt at brevity. There also needs to be a system for accommodating non-group members adding their ideas, dependent on the group's choice about it. There also needs to be flexibility in the stages - this is a full-blown process I've detailed here, and it's HEAVY. Keep in mind, though, that the longest single consensus process I've engaged in lasted for over four months - you want every bit of the structure above in that situation. If you're using consensus for smaller, quicker things, though, then collapsing all the stages together so they can go at once would be helpful - and easy to set up by a site admin. Another configuration in a similar vein would be the option to create some default sets of countdown timers for the decision initiator to pick from. Having pre-sets for "Quick," "Medium," "Long," or "Exhaustive" processes would be very handy and a boon to the UX of this beast.
Additionally, some validation-type algorithms should be written to watch the process for certain types of aberrant behavior - namely, things like clicking into-and-out-of 'Consensus Failure' mode to reset the timer, constantly asking for more time in a stage without submitting anything; things like that. Dunno what we'd do with it - I certainly wouldn't be comfortable EVER allowing it to make unconsulted decisions about group membership, but I do think that it could be useful information to periodically compile into a report and deliver to group members.
As the system matures, I'm hoping that experience can tell us about how certain configurations of settings could be collected into pre-set configurations for certain specific decision types. Those options can then be offered to the process initiator, at least as defaults.
Eaton, in his second point, suggested a tool that might help folks to tease out emerging threads and separate them out. Absolutely, and quite easy to implement. In fact, it's a tool that could live at the API level, and be used in any implementation of the API that cared about keeping track of discussions in such a way. (Eaton's first and third points, I think, were answered implicitly by some of what's here).
As for moshe's point about the user vs. admin - well, it's consensus! As much as possible, there shouldn't be an admin. There are things to be concerned about there, but we're talking about transparency and the preserving the integrity of collective efforts. While site admins need to be able to fix things when broken, if they're able to wank about with the flow or substance of the decision as well, then big question marks start popping up.
Also, just to be ABSOLUTELY clear, this is an example of a very full implementation of the API. Decisionmaking processes don't need to be anywhere NEAR this complex. I'm hoping I'll have time to post some much simpler examples, and maybe show how they can be expanded, but with my time right now I'm just not sure I'll get around to it - at least, not without an outcry of requests for it :)
integration with existing modules
This all looks like you've thought it out in depth, and the example makes it pretty clear how things ought to work. One thing I'd like to know is how it might integrate with existing modules - for example Organic Groups, or core forums, or other places where discussions are created/forked etc. Is this going to be a part of the API, or is that all delegated to individual implementations?
Same with VotingAPI, flag etc. for some voting methods.
While the exact answer will
While the exact answer will (obviously) depend on the module in question, there's a general pattern I'd like to follow:
As for how the integration will work...well. That's where it really varies from module to module. As it pertains to OG, the only type of integration that immediately occurs to me is to have it provide a list of people to participate in a decision - all the members of a group, or some subset of the members of the group. So that's to be done as a 'participants' plugin (that name is just off the top of my head). VotingAPI, on the other hand, could be integrated on a couple few different levels, and I need to think about that one more.
I realize that I also probably ought to draw a distinction between "providing plugins" and "implementations." This is a distinction that'll be familiar to anyone who's worked extensively with Panels, but there's a very clear difference between the two; it's the same difference I noted in my Panels API talk in Szeged:
Plugins provide an additional atomic piece of functionality to the overall engine which may or may not be used by any given implementation.
Implementations are things like the Consensus process I've described above; they piece together a whole bunch of different components (most of which will themselves be plugins) into a single, cohesive process.
Hopefully that makes things clearer, not muddier...
yes, this makes sense
Having plugins for commonly used modules - which are then used (or not) in implementations makes plenty of sense - I'd just not quite seen how this fitted into the proposal. The worst thing would be individual implementations trying to do their own handling off from the main API, not that I think you'd design anything like that of course :) - I don't think I mentioned yet, but I've voted 5 stars for this.
Thats much much clearer.
Thats much much clearer. Thanks Sam. 'll resist the temptation to dive into implementation but I'm tempted given how exciting this is.
Yes!
There are certainly details to be worked out and decisions on implementation that will arise, but I can't stress enough how valuable a tool this will be when done correctly.
All-in-all, I give this proposal 5 stars -- it is a very cool challenge technically and I like the proposal's grounding in community organizing. It is well-researched, relevant to KDI, and fills an established need within community organizations.
Nice
This looks like a really interesting, well thought out and researched proposal. I'm sure it will be useful to any site that needs to have a formalized decision making process. The budget looks reasonable and I know Sam has the coding ability to pull it off. Five stars from me.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Nice app, and the revisions have been great
Voting 5.
FunnyMonkey
Tools for Teachers
FunnyMonkey
Community-funding this proposal
With high praise and approval (after careful questioning) from some of the Drupal community's most respected voices, this proposal was unfortunately not picked up by Knight. We can and should use this opportunity to make community funding one of the pillars Drupal stands on for building great contributed modules.
This org will act as fiscal sponsor, 501c3 for tax deductible donations, with 100% pass-through of funds:
People Who Give a Damn, Inc.
P.O. Box 241
Natick, MA 01760
benjamin, Agaric Design Collective
benjamin, agaric
Standing Aside from Blocking Concerns
Hello,
As a sometime practitioner of formal consensus and modified consensus processes, I would be very interested in this module.
I know you were trying to limit the complexity of the description, so this might already be in your thought processes. For helping to come to consensus on complex topics in particular, it's important that people are able to express the intensity of their concern in stage 2 (their might even be a graduated menu option: e.g. slight concern, minor concern, medium-sized concern, major concern, potentially blocking concern, blocking concern). Similarly, in stage 3, if there are blocking concerns that are "addressed," they are often not fully addressed, so for people to feel comfortable removing their blocks after discussions or modifications, it's important for people to be able to formally express, "Okay, this is no longer a blocking concern for me, but I: a) want my concern about it noted, or b) want to stand aside from this decision and want that noted, or c) don't want to block the whole proposal but want my concerns about a particular aspect noted.
One challenge I think a written consensus process has is that as people write, we tend to lock into positions, and often find it more difficult to shift from opinions we've set down in writing than those we've posited in verbal discussions. This isn't a software challenge per se, but it is a process and usability challenge, and has often been noted as a contributing factor to online flaming. When implementing this module once it gets created, I think we'll have to address this explicitly, and perhaps it could even be built into the software - maybe the software automatically asks folks, for example, who say the concern is a blocking one: "is this truly a blocking concern, or might you feel comfortable with tagging it as a potentially blocking concern?"
Another important innovation of formal consensus was to allow the rest of the group to evaluate whether a stated blocking of consensus meets their criteria for blocks (a block might not meet this criteria for example, if it is truly irrelevant to the discussion at hand, or if it evinces a perspective in contradiction with the core principles of the group). It's a brilliant and important safeguard to have in the process, but I've heard little discussion of it in consensus circles (it became very important to a coalition I'm a part of). Again, this would only apply to your more complex processes, but in such cases there might be a facilitator or facilitators who are designated from the outset as the people who will determine whether a block meets the criteria.
Just to add one more wrinkle into the mix. One group I'm on the national committee (board) of, the War Resisters League, uses a modified consensus process. We strive for consensus in our 2-3 day meetings, but have a fall-back to a 2/3 vote on time-critical decisions. It would be great if in the parameters for the module one could choose fall-back options as well.
I just learned of this idea today, and am sad to hear that it was not funded by Knight. I hope we can find a way to implement it in any case. Thanks for all your work on it so far.
Co-Editor, Peacework Magazine
Global Thought and Local Action for Nonviolent Social Change
www.peaceworkmagazine.org
American Friends Service Committee New England Regional Office
Editor, Peacework
Global Thought and Local Action for Nonviolent Social Change
www.peaceworkmagazine.org (but testing a new OpenPublish-based platform at www.new.peaceworkmagazine.org)
FANTASTIC comments. Thanks!
FANTASTIC comments. Thanks! No surprise, really, since so much of this is rooted in practices Quakers have been instrumental in developing :) Lemme go piece by piece, here...
Re: gradating and timing of concerns. Yep, I'd agree - the division between a 'concerns' and 'blocking concerns' phase may well be artificial in this context. I've found it works better in person, but I suspect that in an online context, it'd just be an unnecessary holdup. And yes, your points about gradation are something I glossed over, but I agree; I'd add that it with the level of concern would probably help to make up for lack of additional cues you get in-person when they say, "So, I have a concern..."
I wasn't aware of those studies, but it doesn't surprise me to hear it at all. It's definitely how I work. There are technical barriers to it, of course, but I am hoping to make integrating audio and/or video contributions as easy as possible - still much less natural than an actual conversation, but hopefully might still lessen lock-in. No doubt there's a LOT of usability work which will need to be done with this (which is why I was so jazzed about the extended implementation testing period in the proposal), but I'm also wary of going too far beyond 'sane defaults.' I don't want people to have to carve anything out to make it work for their use case.
I've had passing thoughts about 'criteria for blocks,' but I'd tended to regard it as a potential black hole of ugliness. It's the type of thing where since it'd be applied in situations where people are already disagreeing, if it's not done well, it could easily turn into just a subversive way of silencing someone. Because I wasn't aware of anyone practicing it successfully, I'd taken it off my mental checklist, but I'm now putting it back on, having heard you say that. The implementation details are potentially sticky, and it's probably something I'd want to invest time in further down the road, but I definitely see the use.
Yup, fallback to voting would absolutely be supported. My current thinking on this is really that decisions will be woven together from constituent parts, which means you'll have a baseline consensus process, then a whole bunch of different pieces you can optionally include, per your specific needs. Analogous to creating node types (in fact, I'm currently vacillating on whether decisionmaking api should work overtop of the node system).
PS - I dunno if you run into Jessica WB with any frequency, but I imagine you do, given that as of my writing this, she's an author of the topmost article at Peacework's site. She could tell you a fair bit about where I'm personally coming from with this project. And if you see her, give her a hug from me :)
I'm guessing this effort has
I'm guessing this effort has died, which is a shame :(
Is there any small steps we could make in this direction for perhaps making our own development process smoother?
Actually, not dead. Just very
Actually, not dead. Just dead with respect to KDI. I gave a presentation at DCPDX a few weeks ago, and am currently in the process of writing up some detailed 'canonical' implementation examples as a first step towards...well, a lot of interrelated ends. If you have something particular in mind, I'd love to discuss it - here, IRC, email, wherever.
This sounds a lot like the
This sounds a lot like the decisions module. This is exactly what we are aiming at with the project: support multiple decision mechanisms to reflect real-world processes.
I think that existing work should not be disregarded.
Key differences from Decisions module
I looked at the Decisions module, and made a deliberate decision to take a separate direction because the Decisions module is specifically focused on numerical voting systems. The engine I've outlined here, and elsewhere, would need to be capable of utilizing numerical voting systems in order to be fully robust, but the above proposal should be quite clear in that it does not think of a 'decision' as being limited to the outcome of a numerical voting process. From my (limited) interaction with the Decisions module, my perception was that it implements most of what the engine would consider a single phase in a decision. The engine is more about making such phases pluggable, replaceable, string-together-able, etc.; in that way, I see it as operating at a lower level than the Decisions module.
Of course, this application did get sidelined, so no code has as yet been written - though there are some recent, promising rumblings. If things end up going forward, I'll take another, more exhaustive look through the code and see where the points of overlap are, and would be happy to avoid duplicating work wherever possible.
decisions aims to do that... in principle
So yes, right now decisions is mostly framed around the votingapi. Even worse: it's node-based, which means you can't vote on comments or "fields" of any sort.
I wish to get rid of that in an eventual 2.0. First, I want decisions to be appliable to any content type (it becomes a field, basically), see 2.0 - allow decisions to be attached to other node types. Second, voting algorithms (IVR, borda, condorcet, 50+1, etc) should be made modules (#532758) so that they can be enable/disabled and applied to other things easily. The decision module would then bridge this stuff in a cohesive "whole".
I think it's exactly what you want to do. The question is: do we start from scratch or reuse the algorigthms already present? Do we reuse votingapi?
So I'm 100% with you on this
So I'm 100% with you on this part:
But this part makes me think we're actually thinking in very different directions:
I've never actually thought of decisions as something to be attached to nodes arbitrarily. In my mind, they're entire workflows comprised of an arbitrary number of phases, each of which potentially encapsulates whole series of discussions (i.e., nodes), individual votes, etc. This was the primary thing that put it in an entirely different problem space as VotingAPI - a point eaton and I agreed on before I wrote this proposal. So reusing VotingAPI is right out, at least.
I think the bigger point, though, is that I don't have time to work on a project of this scope unless it gets funded - really, it's hundreds of hours of work, just to start. As I alluded to before, though, there's a very interesting potential iron in the fire with respect to that right now. So, is it maybe enough to say that I'll let you know if that works out, and we can pick up a more concrete discussion at that point?
let me rephrase
Let me that: I want "decisions" (or I should say votes) to be taken on any content type, so it becomes a field. A decision would still be a node (actually, that would be optional, but in your use case...) that would describe the "proposal" and from there you could branch in multiple content types (discussions, polls, IVR votes, 50%+1 votes, etc). Those "votes" could be taken on the decision itself or on different content types.
But yeah, let's pick up the discussion more concretely later, no problem with that. :) It's just that I was fascinated by this discussion as it's exactly one of the use cases we had in mind when we started working on decisions back in the days... Of course, back in the 4.x days, the notions of "fields" and "content types" weren't so much developed that it made sense to use those paradigms...
Oh and btw, I don't think votingapi is in the way. From what I understand, it can apply to anything really, so it still can be used for the underlying nuts and bolts.
sweet idea
This is a very exciting proposal. I work with churches, and many churches and denominations use Roberts rules of order, or some version of it, to make decisions. So I've been thinking about how to adapt Roberts rules so that some decisions can be made online.
Looking forward to seeing where this goes!
Can we do this in Drupal 7?
To reactivate this, is there any way that the advancements in Drupal 7 could help make different types of consensus models available / easier to set up, via AJAX / new Jquery or Querypath options, or other ways?
Entities, and maybe fields,
Entities, and maybe fields, are potentially beneficial. AJAX is moot, b/c we'd be super-dependent on ctools anyway for plugins, and so we'd have pretty much all of D7 ajax in the ctools ajax framework. I don't see how querypath could be relevant (but that's not core, so it's moot). Having jqui would probably be handy for building good interfaces, but we need an architecture first.
Can't believe I didn't find this
So having been blithely unaware of this post, I had been creating my own module, translating the Formal Consensus process into an online version.
My project page is located here: http://drupal.org/sandbox/TommyKaneko/1090360
And you can see an example of it in action here: http://yourconsensus.org/consensus/sandbox
I would love to hear criticisms of this. The module allows users to create a new "consensus field", which is basically an XML file with lots of info on it. I suppose it's not a very Drupally approach. A lot of the functionality runs through Javascript on the client side. I'd be happy to hear from you regarding your own project....