What are the issues, e.g. in security, quality control, sharing of data and sources?
Are we talking about a wiki, or semantic wiki, here, or are there other ways to implement this?
One problem with Wikipedia is that the talkpages - which is where the difficult issues have to be thrashed out - are not well-organised or structured. We should be able to improve on that system - I'd guess better systems have already been developed, but haven;t looked very far into them yet.
Some comments about policy debate, which may have wider applicability:
David Pavett:
I think that we should spend a little time considering different formats for debate. The trouble with blogs is their rather linear form leading to a jumble of different threads coming from one debate. Bulletin boards overcome this partially with nested threads. The Loomio platform offers a far more sophisticated solution and should be considered. A website which acts as a repository for substantial contributions is almost certainly required. Then we need to talk about how debate can be organised. Left Futures for example has many qualities but the appearance of materials on different issues is virtually random. Can we set debating themes and try to tackle issues collectively? Should be try to produce an on-line magazine? How should debate be moderated? What place, if any, should be given to theoretical issues along with practical ones? if at all?Chris MacMackin:
I'm glad to see that David mentioned the Loomio platform, as it is something which I have come across and found interesting as well. Here are some thoughts I had on a possible structure for a policy discussion system.
- Position papers put forward by experts, think tanks, groups of people directly involved with the issue etc.
- A discussion thread attached to each such paper. The purpose of these would be to provide material for a coherent Response, described below.
- A "response" edited in a Wikipedia-like fashion, expressing general reactions to the position paper. The comments could be used as a means to get material for and to discuss issues with the response.
- Perhaps some sort of meta-response page for each theme (education, strategy, theory, health, etc.) which would reflect people's overall feelings about policy on that theme. This would be drawn from individual response pages on the theme. I feel as though something like a wiki structure might work best for this. From a technical standpoint, I'm not 100% certain how you'd go about coupling position papers to responses, but I'm sure it's possible.
... People contributing to the response papers would need to be members of this site. Perhaps to register they would need to prove membership of Momentum, or something. Momentum's database would have to give everyone a unique identifier. If they could find that out and enter it in when registering, along with the email or postcode they used with Momentum, then their membership could be verified. This would likely require coordination with Momentum in order to happenTim Wilkinson:
an answer to such issues evaluating 'hardness' of facts as mentioned by Chris may involve some kind of scoring system, both of contributors/scorers themselves and contributions/sources
5 comments:
Some more thoughts from me. Sorry if I'm coming over too strong here.
I think the system which I describe above could be a good way to generate discussion and to hear from experts (although other people's thoughts on it are welcome). However, I don't think it would necessarily be appropriate for policy formation. For that, I think something like the approach taken on open source software could be helpful. I don't expect everyone to be aware of how this works and various aspects would have to be altered, so let me lay out a vision below:
A policy commission for some area (the specificity of which would need to be decided) consist of a group of people selected in some way--we'd need to decide on a mechanism to do this which ensure members are making contributions of value but also prevent a "closed shop" from developing. In any case, the commission would consist of no more than a few dozen people. Someone would start the ball rolling by proposing a broad structure to the policy document (sections, subsections, etc.).
This would be the commission's main version of the document, called the "master" version. Revision control software (Git is the most common one in the open source software world) keeps track of the series of changes which are made to the document. All members of the commission would be able to "pull" down the master version to create personal versions. They could then change these personal versions by writing sections of the document, editing someone else's work, etc. The revision control software would keep track of what these changes are relative to the master version. If the master version changes in the meantime, the user can pull down these changes. If there are no conflicts between these new changes and the personal version, then they get merged automatically. Otherwise, the user will have to manually decide what to do with each conflict. Once the user has finished their contribution to the document, they request that it gets merged into the master version (in the software world, this is called a "pull request", as the member is requesting that the master version pulls in their changes). The other members of the commission would then look it over, suggest feedback, and eventually agree on whether or not to accept it. This could be done by vote, although I don't know what to recommend in terms of the size of the majority.
This process of people making their revisions would continue until the commission is satisfied with the document. At this point, it would be made public for some period, during which time, the general membership could discuss it (perhaps using the mechanism I suggested earlier) and, if need be, author their own pull requests. The commission could choose to accept these pull requests or not. The document, with any accepted pull requests, would then go to a general vote. Any pull requests which were not accepted could also be voted on by the general membership. If the vote passes, then this document would enter the policy book. The commission could continue to exist, in order to further refine the policies, update them as circumstances change, etc. When they had completed a major update, they would put the new version (essentially a large, officially sanctioned pull request) to the general membership for another vote.
Presumably we could allow people who aren't members of policy commissions to draft policies as well. Member could nominate it to be included in the general policy. If it received over a certain threshold of nominations (e.g. 10% of the membership), it could go to a general vote. Alternatively, such changes could simply sit there until over half of the membership nominates them, at which point they become policy. We'd need to discuss which mechanism is better.
Continued, as the previous comment wouldn't fit the final paragraph...
Anyway, as someone who has helped develop open source software, I can assure you that this system isn't as complicated to use as it sounds, although our emphasis on democracy and the potential (desire) to involve massive numbers of people does add some extra layers of complexity. From a technical perspective, this would likely be the most difficult part of our ecosystem of tools to build, but a lot of the hardest work around version control has already been done. All we'd have to do is design an interface for it or, if possible, customise one of the existing interfaces.
re: 'coming over too strong' - absolutely not. The more comments the better & these are v useful.
..if not, please find somewhere else to leave your remarks, since they are simply getting in the way of our discussion, and in particular driving other people's comments out of the 'recent comments' list which is intended to keep that discussion going.
I accept the economic analysis is off-topic. I hadnt yet read your scope and aims section of the site which had only gone up the same day and had naturally assumed that economic policy discussion would go in the policy development section.
===
1. The aim is to
a) develop systems for collaborative research
b) policy development
c) the production of informational
d) PR materials.
OK, All Good.
2. The aim here is not to
a) keep changing our discussion format until it is perfect
The functionality and efficiency of a conversation is defined by its format. I'm not expecting perfection. That is a straw man argument.
b) but to get on with the discussion.
When you have tools readily available to make the conversation quicker and more efficient? Why wouldn't we implement them first in this conversation? Before beginning the rest of the conversation?
===
We are trying to assemble notes,
If we, rather than you, are trying to assemble notes, then why arent there notes collections visible and available that we can all edit and trace alterations to, like there is in the Loomio platform?
===
while you keep telling us we should be concentrating on getting a nicer notebook and copying our notes into it.
Improved systems for collaborative research are at the top of your list of aims. The improvements to this discussion i suggest will permit us to work on those aims more quickly. and are thus not just just "nice" but core.
Steven.
Ok this is all reasonable, but at present there are (at least) 3 issues with trying to migrate the conversation onto Loomio.
1. It is going to mean a whole lot of disruption
2. Those who have had a look at Loomio seem unconvinced that it is really suitable either for use in the project itself or as a platform on which to locate these preliminary discussions.
3. We don't really have clear enough ideas or outline documents on which people can focus unco-ordinated editing work
4. Given 3, Loomio etc aren't going to eliminate the need for the conversation to be organised, summarised, collated etc. Changes to a doc made in Wiki-like fashion stiol need their own discussions to occur. On Wikipedia, this happens on unstructured talk pages. Similarly, having lots of history of all amendments, reversions, etc is useful for detailed audit trails but not for moving the discussion forward. For that, information needs to be summarised & organised & the conversation co-ordinated in some way. I'm basically taking on the role of co-ordinator, and intend to continue doing so until a consensus emerges that we have a better way of progressing these discussions, and are ready and able to implement it without having to suspend communications (possibly for some time while unforeseen problems are dealt with).
In the future, it will certainly be good to develop a much better platform (probably using the same kind of tech we use in our main operational systems) for the strategy group/steering committe/whatever to use. But for the reasons given, I don't think we are at that point by a long chalk.
I can make (and have made) piecemeal - non-disruptive - improvements to this (admittedly rudimentary) platform in response to concrete suggestions which indentify verifiable problems. For the moment that will have to do.
I do appreciate your interest in the project. If you want to help move it forward, one really useful thing you could do is some research and testing on the stuff mentioned in this comment: http://strategy.labourroots.uk/2016/06/technologies-001.html?showComment=1466030613859#c5272656788395345379 , reporting back with findings. Only a suggestion, but could be a good use of your web site perhaps?
Post a Comment