Fwd: Re: changes to Econsensus
9 views
Skip to first unread message
Tom Lord
Jan 10, 2013, 9:56:52 AM1/10/13
to econsens...@googlegroups.com
copying in this long and I hope useful discussion here.
-------- Original Message --------
Subject: Re: changes to Econsensus
Date: Thu, 10 Jan 2013 13:01:50 +0000
From: Tom Lord <to...@aptivate.org>
To: f...@open2flow.co.uk
Hey Francois,
You have raised many salient points here, and so this reply is quite
long...
> Anyway, my first request, as a result of this slower pace, I can never
> remember the very long url
> https://econsensus.org/sociocracyuk/item/list/proposal, I keep having to
> spend time having to look it up, and I'm the most frequent user. Is there
> any way we could have our original home page url back, ie. Just
> https://econsensus.org/sociocracyuk ? That much I can remember. It would
> still point to the same proposal list page (once logged in), it was so much
> easier before.
I hear you - I can see that it might be useful, if you don't want to
bookmark the page, to allow the user to type in
econsensus.org/[organisation name] as a shortcut . I wonder how long
this would take us to implement...
However, have you tried just going to econsensus.org and logging in
there? That will work just fine, and should be easy to remember :-)
Caveat - at this precise moment if you log in to econsensus.org , I
think you will be presented with a list of your organisations (i.e. only
Sociocracy UK for you) and will need to click on "Sociocracy UK" to get
to the proposals page. In the next week or two we will be making a
change so that you are automatically logged in to your organisation, if
you only have one organisation. So you should only need to remember
econsensus.org .
> I personally used to have two log ins, one as 'admin' with administration
> rights, and my own with just normal access. The admin log in seems to
> have been disabled, yet my own log in seems to give me admin rights.
> Does everyone now have admin rights? Although the admin log in is disabled,
> it still exists as a member in the member's list, can I delete it?
Thanks for pointing this out - I don't think we made this issue clear
during the migration a few months ago to having one application serving
multiple organisations.
Early organisations like Sociocracy UK, that had their own individual
econsensus system, had an "Admin" user. This no longer works on the new
econsensus, which hosts multiple organisations in one system. Your user
is an admin user for Sociocracy UK. Other users of your org are not
admin users, and cannot add, edit or delete members, or change the name
of or delete the organisation - and as an admin, you can give other
users admin rights, using the admin interface.
Thanks for pointing out that you could still see the old "Admin" account
listed in your organisation - that wasn't intentional and we have now
removed it.
> In answer to your question below, when I said 'historical versions of
> feedback' that was possibly a misnomer. All I was trying to point out was
> that each feedback comment remains listed in chronological order under each
> proposal, even if a proposal has subsequently been modified and improved,
> whereas in contrast each modification of a proposal itself is not recorded.
> However, since we have in the meantime clarified the issue of the EDIT link,
> this point is no longer so relevant or important, so let's just leave it as
> it is for the time being. I understand what you're saying about
> updating/amending feedback and being able to reply within, it is
> increasingly becoming like a forum, but let us try it out as it is currently
> set up and see what happens.
I agree - the proposal making functionality is like a specialised forum.
> One of the difficulties I've had trying to encourage the others to use
> econsensus is that we keep having to revert to other software to complete a
> task, e.g. in this case a wiki. If the editable proposal are was more like
> a wiki, then I think it would be easier, even though for many decision types
> this isn't really necessary, as you say. Anyway, for now let's leave that
> as it is.
Yes. :-) There are always tensions between making One Big System that
does everything you could want, and using a pool of existing separate
components that do one thing well.
For a proposal where you want to agree on a document that will have
several revisions, I agree that linking away to a wiki or an online
collaborative document etc. that can track revisions well, will be the
way forward at the moment.
We do have a suggestion in the pile to make edits to the proposal text
wiki-like in terms of tracking changes and versions. At the moment I
this is of medium priority, which means that it isn't likely to be
implemented in the next few months, however depending on the amount of
time and energy this project gets, it may happen this year. Hard to say
right now.
> Some more requests or comments:
>
> - Could the main Edit link be made a bit bigger or as a button, so it's more
> obvious?
I see what you mean. I'll have a chat with our stylists about this.
> - When creating a new proposal there is no longer any notification going out
> to all by email saying that someone has created a new proposal. Can that be
> re-instated?
Oh! Users should receive emails of any changes on the system. I'm very
interested in looking into this with you if you can provide more details.
Note that if you created the proposal, you won't receive notification of
it, although everyone else will - is this what has happened? This is by
design - within Aptivate I think we felt that we were getting enough
email from the system to not want to see our own proposals as emails.
However we could talk about re-instating this, or making it an option
once we have a communication options page (as below).
> - By contrast the Watch tick box is ticked by default, which means that
> every time someone adds a full stop or corrects a spelling mistake in the
> proposal box everyone gets plethora of emails by default. In my view the
> default should be the other way round: receive initial new proposal notice -
> yes, receive subsequent modification or feedback notice - no (but initial
> email to point this out).
Thanks for the feedback on this.
The reason it is as it is, is that we wanted to make the system as close
to an email discussion as possible in terms of its verboseness. So, if
you're using email to track your decisions, and you want to change
anything or make any feedback or whatever, you would either put a link
in your email to an online collaborative document that can change a lot,
or you would put the new text in the body of the email and you would
have to send a new email every time you wanted to change the text.
I wonder if you are using the proposal text to do what we were talking
about above - revising versions of text several times, to get consensus
on a particular wording. We didn't initially intend the proposal text
box to be used for this, and in this use case I can see that people will
get lots of emails, probably too many. I would suggest that using an
online document collaboration system, even something very simple like
www.lopad.org , and linking to it from the proposal, might work better
for now.
In the future, I can imagine us having a "this is a minor edit" tick-box
by the edit button that would mean that no email is sent out for things
like typos etc. I can see that being useful - I'll create a task for this.
If we do as you suggest and make discussions opt-in, then most of the
decision making process will become "hidden" to most people in an
organisation. We actively didn't want to do this - I suspect that it
will lead to most people not noticing the decision making process
happening, and decisions being made in effect by only a few people in a
closed dark room, and people thinking that the tool does not help
transparency.
However, I accept that I don't know for sure whether this is true or
not! We have talked about it being useful for both individual users and
whole organisations to set preferences about how notifications happen. I
will look at increasing the priority of this feature to allow orgs and
individuals to play with their communication preferences and see what works.
> - Why is the Watch tick box inside the edit function. Every time someone
> changes their watch setting everyone gets an email. Can the box put
> outside? (I thought the Watch tick box was part of everyone's personal
> setting?)
I agree, and I very much appreciate you pointing that out! Thanks :-)
I'll create a task for this.
> - When archiving there is a Date archived box. Can that be automated to when
> it is actually archived?
Agreed, that would be nice wouldn't it. Similarly it might be nice to
have an automatic creation date, and a date when anything changed state
into anything else. We do have tasks noted for functionality like this,
and they are not highest priority right now, because people haven't
argued a case for making them high priority. So, if needing to know
exactly when something was archived is important to your workflow, do
let us know! In general we haven't put much effort into the Archive as
we don't find it being used much.
I hope you will be pleased to hear that one of the things we have been
prioritising recently instead, is tracking action items on decisions,
and assigning users and dates to them! We should have a user interface
for this within the next couple of weeks.
> - When changing status from proposal to decision, one then has to go into
> Edit mode to add the relevant dates (causing yet another email to go out
> unless the default is changed). I'm not sure what to suggest, but it seems
> to me there should be a more ceremonious way of transforming a proposal into
> a decision where all the relevant dates can be entered at the same time.
I see what you mean, yes, we were just today talking about working out
how to reduce the number of emails that go out during a transition, and
I hadn't considered this case. Great! We will make a task card for it.
Hmmm. Yes I'm not sure either what the user interface should be for this
off the top of my head - an interesting challenge for us, thanks!
> - Can the date labels be changed as follows:
> - Decided: same
> - Effective: same (ideally by default initially automatically same
> date as decided)
> - Review: 'Next review or expiry'
> - Expiry: 'Last reviewed'
> Note: I have assigned the 'Next review or expiry' under the current
> 'Review', because that is the (one of two) field that shows up in the
> overview table (list) and that's the most important date I need to be able
> to see in the list. However, logically 'last reviewed' should come before
> 'Next review' in the decision box. You had in the past mentioned user
> defined labels, I can imagine others wanting to have different labels.
Agree that knowing if a review has actually happened would be nice.
I see what you are saying with regard to changing the titles of the
columns. Maybe keeping the "expiry" column and adding a separate "last
review" column would give us most options, as it may be nice to still
record the intended "expiry" date of a decision, separately to some
frequent reviews.
Is this something you want to do within Sociocracy UK right now? If you
can explain more detail about how you work and how you would use this
functionality, that will help us understand and prioritise tasks.
There are an infinite number of things that could be done to improve the
software, and the more that people tell us about their real world
example of why it would make a difference, the more likely we will
prioritise those tasks! It will also help us to make sure that when we
create some functionality, it will be as useful as possible and not miss
the point.
> - Can two more boxes be added in decision mode?
> - Review period (text box, to enter frequency of review, e.g.
> annually, bi-monthly......)
> - Measurement (text box, to enter how a policy is going to be
> measured)
> In its place, can the five coloured boxes with feedback types be
> removed (in decision mode only), as once decision taken this is irrelevant
> (and the feedback boxes below remain).
I can see that a "recurring" function on the review dates could be
useful. I will add a task card for that.
With regard to measurement - could you explain a bit more about how
having this would be more helpful for you than writing the method of
reviewing the decision in the main body of the text, which you can do at
the moment?
Interestingly, this sounds like it is straying into the territory of
another tool we want to write at the moment, which is one to assist in
Monitoring and Evaluation, i.e. measuring impact against certain
indicators. This is an Official International Development Concept,
however obviously it is a generally useful concept for any organisation,
as you are describing here. It would be very interesting for us to hear
how you might use this functionality.
> - Is it possible to distinguish between feedback entered before and after a
> decision is made? If so please enable (in which case one might consider
> keeping the coloured boxes but counting only the new feedback; in other
> words these would be issues that need to be looked at when a decision is
> reviewed)
You mean, people could review a decision and raise concerns on
Econsensus after the decision has been made? That is an interesting use
case, and sounds quite plausible if decisions are being reviewed. I
wonder how we could record newer feedback. Maybe the cheapest, least
tricky option would be that we could reverse the order that feedback
appears, to be most recent highest.
There are some issues with trying to put a fixed marker in the timeline
of a decision's life. E.g. people can continue to discuss previous
concerns, or a decision can in theory change its state between proposal,
decision and archive multiple times, or a decision could as you say have
multiple review stages. We could try though...
Thinking about this, I wonder if we could have the option to mark
feedback as "old". People could then see what was more recent, and mark
"old" feedback as "current" again if an issue raised its head again. We
could then have the option to view only "current" feedback, or both
"current" and "old" feedback.
This functionality could then also be used during the proposal stage to
note feedback that has been resolved, e.g. by discussion or by changing
the proposal.
> - Is it possible to re-label the feedback types as follows (or enable user
> definitions)
> - Question = Question (same) 1
> - Danger = Objection 4
> - Concerns = Concern 3
> - Consent = Consent (same) 5
> - Comment = Reaction 2
> And to reorder them in the order number given above.
Firstly, I agree that I can't come up with a good reason for the current
order as it stands. We could certainly put questions and comments
together; I think they are conceptually different to consenting or
"objecting" to something.
I also don't know why Concerns is plural!
The reason that there is an ordering of Danger > Concerns > Consent is
that it is an approximation to the Likert scale used in Dotmocracy, and
it is in order of objection to the proposal. E.g. Danger is more
objectionable than Concerns, which is more objectionable than Consent.
The words are ones that people in Aptivate felt comfortable with. I
totally agree that other organisations will prefer to choose their own
terminology, and also potentially have different numbers of terms, not 5
as we have now. We absolutely don't want to be culturally imperialistic
in terms of forcing people to use a certain way of working, or simply
put people off by using words that don't feel right.
We do have a task card for this right now. However, my understanding is
that it is quite a major change to the guts of the system, not as easy
as I hoped. I think we may have not built flexibility in from the start,
so now the system assumes those terms.
It's interesting to hear that you would like to change these terms, and
also interesting to note that you seem happy with the general 5 types we
have made available, if not the exact names!
Thanks again for the time you have put into thinking about this,
Francois. I hope this is helpful and would be very happy to discuss
anything further or have a phone call if useful.
best regards,
Tom.
>
>
>
> -----Original Message-----
> From: Tom Lord [mailto:to...@aptivate.org]
> Sent: 03 December 2012 12:15
> To: f...@open2flow.co.uk; openconse...@googlegroups.com
> Subject: Re: changes to Econsensus
>
> Hey Francois,
>
>
> On 02/12/12 19:12, Francois Knuchel wrote:
>> Hi Tom
>>
>> Thanks for your response. My apologies for having expressed myself
>> poorly, evident from your interpretation of what I had intended to
>> say; that plus the fact that we have been using Econsensus in a
>> slightly wrong way, your comments have made that clear to me.
>>
>> It had not occurred to us to use the edit button to modify the
>> proposal [indeed was that 'edit' button always there??? :)], somehow
>> that eluded us, it seems so obvious now, but that completely changes
>> our perspective. OK, I understand now, using the edit button means we
>> always have the latest version of the proposal at the top.
>
> Oh!! That explains a lot :-) I'm really glad we had this conversation,
> thanks!
>
> Although I couldn't swear, I'm pretty sure that Edit link has always been
> available! Maybe it just wasn't placed as helpfully as it could have been -
> we have re-styled the site a bit. Anyway, good to hear that we have reached
> new understanding! Sorry you folks spent a while scratching your heads at
> it; I hope it's relatively self-explanatory now. It sounds like we are not
> making the system as clear as we could, so I'd appreciate understanding how
> you thought we intended it to be used, as per the feedback discussion below.
>
>> I completely agree with your point (with one exception - see below)
>> that we do not need to keep or view previous (historical) versions of
>> a proposal - indeed that was exactly my complaint, that the very
>> original obsolete proposal wording was always at the very top, rather
>> than the latest version, but that was, as I now realise, because we
>> weren't using the edit button to modify the proposal (instead
>> reverting to modifications within feedback boxes - obviously
>> cumbersome). Right, so given that clarification, we'll try again, that
> does change things.
>>
>> My suggestion then is, if we're not keeping historical versions of the
>> proposal, why are we keeping historical versions of the feedback.
>> Either we track versions of both or of neither, why one not the other?
>> But at the very least, my suggestion is that Feedback comments should
>> display in reverse chronological order, i.e. with the very latest
>> feedback at the top, and the older stuff further below. At least then
>> the most current stuff, both proposal and feedback, is at the very top.
>
> Once again, I think we have reached a point of potential new understanding
> :-) Can you explain to me how you are thinking we intended there to be
> historical versions of feedback? Our intention is that people can add as
> many (different) feedback items as they like.
> They can also edit existing feedback items (by clicking the edit link,
> again!) if their understanding or opinion changes, e.g. change wording, or
> change a concern to a consent.
>
> We did not intend that people submit an item of feedback and then add
> another one further down the page, to in effect cancel the one above, if
> their understanding or opinion changed. Is that what you mean by historical
> versions?
>
> So, given that, the reason the feedback is ordered earliest first is that it
> forms a conversation starting with the original proposal, and flowing down
> the page. E.g. people add concerns, some people reply to those concerns with
> comments later down the page, etc.
>
>
> Related to this topic is the news that we are just about to add new
> functionality which will allow replies to be posted inline to individual
> feedback items. So, e.g. if I make a proposal "let's buy a new office!"
> and Nate raises a concern "this will cost a lot of money", up until now the
> only way for me to have a conversation with Nate about this was to add e.g.
> a new "Comment" feedback item below, and then Nate to post a comment below
> that, etc. The new functionality will allow me (and anyone
> else) to post replies inline to that feedback item (using email or the web
> interface), so that it is clear that the conversation is all related to that
> particular piece of feedback.
>
>> I agree with most of your comments, and I must say I cannot recall
>> having tried to compare what we were doing with what you were doing -
>> indeed, how could I?, I have absolutely no idea what you are doing.
>> What I think I was trying to compare was what we were doing and what
>> the software appeared to be asking us to do (implied assumptions),
>> though as is clear to me now that was our misreading of the software.
>> In hindsight, how could we have missed that 'edit' button???
>>
>> As to whether we should introduce the option of tracking older
>> proposal wordings (much like a wiki), I agree, that in most cases that
>> shouldn't be necessary, though it seems this is a question I should put to
> the others.
>> In the particular example we were using, the wording itself was the
>> essence of the proposal under discussion (i.e. mission statement,
>> V-M-A wording), where we were already agreed on the content, but not
>> on how that content should be worded, and hence a lot of discussion
>> was about trialling out different wordings, reverting, no xxx's
>> version sounded better (what was it
>> again?) etc etc.. So there are cases where tracking would be very
>> useful (indeed we subsequently moved the discussion to a wiki) -
>> however, I suspect this is more an exception than a rule, so at this
>> stage I leave the question open as to whether tracking is necessary or
>> not (I suspect desirable as an option, but not necessary).
>
> I can see that it might be useful in a few cases, however as you say, I
> think this is a rare and particular kind of decision, not one that comes up
> in most decisions.
>
> I think that for this sort of proposal, I might well use a collaborative
> document writing system that can save revisions, such as google docs, or
> lopad, or a wiki, etc. and then link to whatever tool I was using from my
> proposal in Econsensus. I think that your moving the practical
> implementation of this kind of task to a wiki makes a lot of sense with the
> level of functionality we have in Econsensus right now, and just leaving the
> discussion of the task in Econsensus.
>
> There's always a tension between replicating functionality from other tools
> in a new tool, or leaving them separate and using both. I can still see
> potential reasons for including this functionality in Econsensus, to help
> bigger groups track who is changing what when, and it feels like as the
> project gets bigger and goes on for more time, we are starting to be more
> shrewd about adding more time and functionality to the project!
>
>
>> Given my renewed understanding of how the software is supposed to
>> work, I am going to try to get everyone to use it again, so hopefully
>> we'll be able to give you more useful feedback in the future.
>>
>> Thanks for the clarification. All the best.
>>
>> Francois
>
> That's great to hear, thanks Francois!
>
> If any of what I'm saying still doesn't make sense then if you'd be up for
> scheduling a call sometime when you can walk me through the system that
> would be great. Alternatively, I can create demonstration items relating to
> what I'm talking about in our public Sandbox system for you to see and
> comment on.
>
> cheers,
> Tom.
>
> --
> Tom Lord | (to...@aptivate.org)
>
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967838 Future Business,
> Cambridge City FC, Milton Road, Cambridge CB4 1UY
>
> Aptivate is a not-for-profit company registered in England and Wales with
> company number 04980791.
>
--
Tom Lord | (to...@aptivate.org)
Aptivate | http://www.aptivate.org | Phone: +44 1223 967838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
Tom Lord | (to...@aptivate.org)
Aptivate | http://www.aptivate.org | Phone: +44 1223 967838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
-------- Original Message --------
Subject: Re: changes to Econsensus
Date: Thu, 10 Jan 2013 13:01:50 +0000
From: Tom Lord <to...@aptivate.org>
To: f...@open2flow.co.uk
Hey Francois,
You have raised many salient points here, and so this reply is quite
long...
> Anyway, my first request, as a result of this slower pace, I can never
> remember the very long url
> https://econsensus.org/sociocracyuk/item/list/proposal, I keep having to
> spend time having to look it up, and I'm the most frequent user. Is there
> any way we could have our original home page url back, ie. Just
> https://econsensus.org/sociocracyuk ? That much I can remember. It would
> still point to the same proposal list page (once logged in), it was so much
> easier before.
I hear you - I can see that it might be useful, if you don't want to
bookmark the page, to allow the user to type in
econsensus.org/[organisation name] as a shortcut . I wonder how long
this would take us to implement...
However, have you tried just going to econsensus.org and logging in
there? That will work just fine, and should be easy to remember :-)
Caveat - at this precise moment if you log in to econsensus.org , I
think you will be presented with a list of your organisations (i.e. only
Sociocracy UK for you) and will need to click on "Sociocracy UK" to get
to the proposals page. In the next week or two we will be making a
change so that you are automatically logged in to your organisation, if
you only have one organisation. So you should only need to remember
econsensus.org .
> I personally used to have two log ins, one as 'admin' with administration
> rights, and my own with just normal access. The admin log in seems to
> have been disabled, yet my own log in seems to give me admin rights.
> Does everyone now have admin rights? Although the admin log in is disabled,
> it still exists as a member in the member's list, can I delete it?
Thanks for pointing this out - I don't think we made this issue clear
during the migration a few months ago to having one application serving
multiple organisations.
Early organisations like Sociocracy UK, that had their own individual
econsensus system, had an "Admin" user. This no longer works on the new
econsensus, which hosts multiple organisations in one system. Your user
is an admin user for Sociocracy UK. Other users of your org are not
admin users, and cannot add, edit or delete members, or change the name
of or delete the organisation - and as an admin, you can give other
users admin rights, using the admin interface.
Thanks for pointing out that you could still see the old "Admin" account
listed in your organisation - that wasn't intentional and we have now
removed it.
> In answer to your question below, when I said 'historical versions of
> feedback' that was possibly a misnomer. All I was trying to point out was
> that each feedback comment remains listed in chronological order under each
> proposal, even if a proposal has subsequently been modified and improved,
> whereas in contrast each modification of a proposal itself is not recorded.
> However, since we have in the meantime clarified the issue of the EDIT link,
> this point is no longer so relevant or important, so let's just leave it as
> it is for the time being. I understand what you're saying about
> updating/amending feedback and being able to reply within, it is
> increasingly becoming like a forum, but let us try it out as it is currently
> set up and see what happens.
I agree - the proposal making functionality is like a specialised forum.
> One of the difficulties I've had trying to encourage the others to use
> econsensus is that we keep having to revert to other software to complete a
> task, e.g. in this case a wiki. If the editable proposal are was more like
> a wiki, then I think it would be easier, even though for many decision types
> this isn't really necessary, as you say. Anyway, for now let's leave that
> as it is.
Yes. :-) There are always tensions between making One Big System that
does everything you could want, and using a pool of existing separate
components that do one thing well.
For a proposal where you want to agree on a document that will have
several revisions, I agree that linking away to a wiki or an online
collaborative document etc. that can track revisions well, will be the
way forward at the moment.
We do have a suggestion in the pile to make edits to the proposal text
wiki-like in terms of tracking changes and versions. At the moment I
this is of medium priority, which means that it isn't likely to be
implemented in the next few months, however depending on the amount of
time and energy this project gets, it may happen this year. Hard to say
right now.
> Some more requests or comments:
>
> - Could the main Edit link be made a bit bigger or as a button, so it's more
> obvious?
I see what you mean. I'll have a chat with our stylists about this.
> - When creating a new proposal there is no longer any notification going out
> to all by email saying that someone has created a new proposal. Can that be
> re-instated?
Oh! Users should receive emails of any changes on the system. I'm very
interested in looking into this with you if you can provide more details.
Note that if you created the proposal, you won't receive notification of
it, although everyone else will - is this what has happened? This is by
design - within Aptivate I think we felt that we were getting enough
email from the system to not want to see our own proposals as emails.
However we could talk about re-instating this, or making it an option
once we have a communication options page (as below).
> - By contrast the Watch tick box is ticked by default, which means that
> every time someone adds a full stop or corrects a spelling mistake in the
> proposal box everyone gets plethora of emails by default. In my view the
> default should be the other way round: receive initial new proposal notice -
> yes, receive subsequent modification or feedback notice - no (but initial
> email to point this out).
Thanks for the feedback on this.
The reason it is as it is, is that we wanted to make the system as close
to an email discussion as possible in terms of its verboseness. So, if
you're using email to track your decisions, and you want to change
anything or make any feedback or whatever, you would either put a link
in your email to an online collaborative document that can change a lot,
or you would put the new text in the body of the email and you would
have to send a new email every time you wanted to change the text.
I wonder if you are using the proposal text to do what we were talking
about above - revising versions of text several times, to get consensus
on a particular wording. We didn't initially intend the proposal text
box to be used for this, and in this use case I can see that people will
get lots of emails, probably too many. I would suggest that using an
online document collaboration system, even something very simple like
www.lopad.org , and linking to it from the proposal, might work better
for now.
In the future, I can imagine us having a "this is a minor edit" tick-box
by the edit button that would mean that no email is sent out for things
like typos etc. I can see that being useful - I'll create a task for this.
If we do as you suggest and make discussions opt-in, then most of the
decision making process will become "hidden" to most people in an
organisation. We actively didn't want to do this - I suspect that it
will lead to most people not noticing the decision making process
happening, and decisions being made in effect by only a few people in a
closed dark room, and people thinking that the tool does not help
transparency.
However, I accept that I don't know for sure whether this is true or
not! We have talked about it being useful for both individual users and
whole organisations to set preferences about how notifications happen. I
will look at increasing the priority of this feature to allow orgs and
individuals to play with their communication preferences and see what works.
> - Why is the Watch tick box inside the edit function. Every time someone
> changes their watch setting everyone gets an email. Can the box put
> outside? (I thought the Watch tick box was part of everyone's personal
> setting?)
I agree, and I very much appreciate you pointing that out! Thanks :-)
I'll create a task for this.
> - When archiving there is a Date archived box. Can that be automated to when
> it is actually archived?
Agreed, that would be nice wouldn't it. Similarly it might be nice to
have an automatic creation date, and a date when anything changed state
into anything else. We do have tasks noted for functionality like this,
and they are not highest priority right now, because people haven't
argued a case for making them high priority. So, if needing to know
exactly when something was archived is important to your workflow, do
let us know! In general we haven't put much effort into the Archive as
we don't find it being used much.
I hope you will be pleased to hear that one of the things we have been
prioritising recently instead, is tracking action items on decisions,
and assigning users and dates to them! We should have a user interface
for this within the next couple of weeks.
> - When changing status from proposal to decision, one then has to go into
> Edit mode to add the relevant dates (causing yet another email to go out
> unless the default is changed). I'm not sure what to suggest, but it seems
> to me there should be a more ceremonious way of transforming a proposal into
> a decision where all the relevant dates can be entered at the same time.
I see what you mean, yes, we were just today talking about working out
how to reduce the number of emails that go out during a transition, and
I hadn't considered this case. Great! We will make a task card for it.
Hmmm. Yes I'm not sure either what the user interface should be for this
off the top of my head - an interesting challenge for us, thanks!
> - Can the date labels be changed as follows:
> - Decided: same
> - Effective: same (ideally by default initially automatically same
> date as decided)
> - Review: 'Next review or expiry'
> - Expiry: 'Last reviewed'
> Note: I have assigned the 'Next review or expiry' under the current
> 'Review', because that is the (one of two) field that shows up in the
> overview table (list) and that's the most important date I need to be able
> to see in the list. However, logically 'last reviewed' should come before
> 'Next review' in the decision box. You had in the past mentioned user
> defined labels, I can imagine others wanting to have different labels.
Agree that knowing if a review has actually happened would be nice.
I see what you are saying with regard to changing the titles of the
columns. Maybe keeping the "expiry" column and adding a separate "last
review" column would give us most options, as it may be nice to still
record the intended "expiry" date of a decision, separately to some
frequent reviews.
Is this something you want to do within Sociocracy UK right now? If you
can explain more detail about how you work and how you would use this
functionality, that will help us understand and prioritise tasks.
There are an infinite number of things that could be done to improve the
software, and the more that people tell us about their real world
example of why it would make a difference, the more likely we will
prioritise those tasks! It will also help us to make sure that when we
create some functionality, it will be as useful as possible and not miss
the point.
> - Can two more boxes be added in decision mode?
> - Review period (text box, to enter frequency of review, e.g.
> annually, bi-monthly......)
> - Measurement (text box, to enter how a policy is going to be
> measured)
> In its place, can the five coloured boxes with feedback types be
> removed (in decision mode only), as once decision taken this is irrelevant
> (and the feedback boxes below remain).
I can see that a "recurring" function on the review dates could be
useful. I will add a task card for that.
With regard to measurement - could you explain a bit more about how
having this would be more helpful for you than writing the method of
reviewing the decision in the main body of the text, which you can do at
the moment?
Interestingly, this sounds like it is straying into the territory of
another tool we want to write at the moment, which is one to assist in
Monitoring and Evaluation, i.e. measuring impact against certain
indicators. This is an Official International Development Concept,
however obviously it is a generally useful concept for any organisation,
as you are describing here. It would be very interesting for us to hear
how you might use this functionality.
> - Is it possible to distinguish between feedback entered before and after a
> decision is made? If so please enable (in which case one might consider
> keeping the coloured boxes but counting only the new feedback; in other
> words these would be issues that need to be looked at when a decision is
> reviewed)
You mean, people could review a decision and raise concerns on
Econsensus after the decision has been made? That is an interesting use
case, and sounds quite plausible if decisions are being reviewed. I
wonder how we could record newer feedback. Maybe the cheapest, least
tricky option would be that we could reverse the order that feedback
appears, to be most recent highest.
There are some issues with trying to put a fixed marker in the timeline
of a decision's life. E.g. people can continue to discuss previous
concerns, or a decision can in theory change its state between proposal,
decision and archive multiple times, or a decision could as you say have
multiple review stages. We could try though...
Thinking about this, I wonder if we could have the option to mark
feedback as "old". People could then see what was more recent, and mark
"old" feedback as "current" again if an issue raised its head again. We
could then have the option to view only "current" feedback, or both
"current" and "old" feedback.
This functionality could then also be used during the proposal stage to
note feedback that has been resolved, e.g. by discussion or by changing
the proposal.
> - Is it possible to re-label the feedback types as follows (or enable user
> definitions)
> - Question = Question (same) 1
> - Danger = Objection 4
> - Concerns = Concern 3
> - Consent = Consent (same) 5
> - Comment = Reaction 2
> And to reorder them in the order number given above.
Firstly, I agree that I can't come up with a good reason for the current
order as it stands. We could certainly put questions and comments
together; I think they are conceptually different to consenting or
"objecting" to something.
I also don't know why Concerns is plural!
The reason that there is an ordering of Danger > Concerns > Consent is
that it is an approximation to the Likert scale used in Dotmocracy, and
it is in order of objection to the proposal. E.g. Danger is more
objectionable than Concerns, which is more objectionable than Consent.
The words are ones that people in Aptivate felt comfortable with. I
totally agree that other organisations will prefer to choose their own
terminology, and also potentially have different numbers of terms, not 5
as we have now. We absolutely don't want to be culturally imperialistic
in terms of forcing people to use a certain way of working, or simply
put people off by using words that don't feel right.
We do have a task card for this right now. However, my understanding is
that it is quite a major change to the guts of the system, not as easy
as I hoped. I think we may have not built flexibility in from the start,
so now the system assumes those terms.
It's interesting to hear that you would like to change these terms, and
also interesting to note that you seem happy with the general 5 types we
have made available, if not the exact names!
Thanks again for the time you have put into thinking about this,
Francois. I hope this is helpful and would be very happy to discuss
anything further or have a phone call if useful.
best regards,
Tom.
>
>
>
> -----Original Message-----
> From: Tom Lord [mailto:to...@aptivate.org]
> Sent: 03 December 2012 12:15
> To: f...@open2flow.co.uk; openconse...@googlegroups.com
> Subject: Re: changes to Econsensus
>
> Hey Francois,
>
>
> On 02/12/12 19:12, Francois Knuchel wrote:
>> Hi Tom
>>
>> Thanks for your response. My apologies for having expressed myself
>> poorly, evident from your interpretation of what I had intended to
>> say; that plus the fact that we have been using Econsensus in a
>> slightly wrong way, your comments have made that clear to me.
>>
>> It had not occurred to us to use the edit button to modify the
>> proposal [indeed was that 'edit' button always there??? :)], somehow
>> that eluded us, it seems so obvious now, but that completely changes
>> our perspective. OK, I understand now, using the edit button means we
>> always have the latest version of the proposal at the top.
>
> Oh!! That explains a lot :-) I'm really glad we had this conversation,
> thanks!
>
> Although I couldn't swear, I'm pretty sure that Edit link has always been
> available! Maybe it just wasn't placed as helpfully as it could have been -
> we have re-styled the site a bit. Anyway, good to hear that we have reached
> new understanding! Sorry you folks spent a while scratching your heads at
> it; I hope it's relatively self-explanatory now. It sounds like we are not
> making the system as clear as we could, so I'd appreciate understanding how
> you thought we intended it to be used, as per the feedback discussion below.
>
>> I completely agree with your point (with one exception - see below)
>> that we do not need to keep or view previous (historical) versions of
>> a proposal - indeed that was exactly my complaint, that the very
>> original obsolete proposal wording was always at the very top, rather
>> than the latest version, but that was, as I now realise, because we
>> weren't using the edit button to modify the proposal (instead
>> reverting to modifications within feedback boxes - obviously
>> cumbersome). Right, so given that clarification, we'll try again, that
> does change things.
>>
>> My suggestion then is, if we're not keeping historical versions of the
>> proposal, why are we keeping historical versions of the feedback.
>> Either we track versions of both or of neither, why one not the other?
>> But at the very least, my suggestion is that Feedback comments should
>> display in reverse chronological order, i.e. with the very latest
>> feedback at the top, and the older stuff further below. At least then
>> the most current stuff, both proposal and feedback, is at the very top.
>
> Once again, I think we have reached a point of potential new understanding
> :-) Can you explain to me how you are thinking we intended there to be
> historical versions of feedback? Our intention is that people can add as
> many (different) feedback items as they like.
> They can also edit existing feedback items (by clicking the edit link,
> again!) if their understanding or opinion changes, e.g. change wording, or
> change a concern to a consent.
>
> We did not intend that people submit an item of feedback and then add
> another one further down the page, to in effect cancel the one above, if
> their understanding or opinion changed. Is that what you mean by historical
> versions?
>
> So, given that, the reason the feedback is ordered earliest first is that it
> forms a conversation starting with the original proposal, and flowing down
> the page. E.g. people add concerns, some people reply to those concerns with
> comments later down the page, etc.
>
>
> Related to this topic is the news that we are just about to add new
> functionality which will allow replies to be posted inline to individual
> feedback items. So, e.g. if I make a proposal "let's buy a new office!"
> and Nate raises a concern "this will cost a lot of money", up until now the
> only way for me to have a conversation with Nate about this was to add e.g.
> a new "Comment" feedback item below, and then Nate to post a comment below
> that, etc. The new functionality will allow me (and anyone
> else) to post replies inline to that feedback item (using email or the web
> interface), so that it is clear that the conversation is all related to that
> particular piece of feedback.
>
>> I agree with most of your comments, and I must say I cannot recall
>> having tried to compare what we were doing with what you were doing -
>> indeed, how could I?, I have absolutely no idea what you are doing.
>> What I think I was trying to compare was what we were doing and what
>> the software appeared to be asking us to do (implied assumptions),
>> though as is clear to me now that was our misreading of the software.
>> In hindsight, how could we have missed that 'edit' button???
>>
>> As to whether we should introduce the option of tracking older
>> proposal wordings (much like a wiki), I agree, that in most cases that
>> shouldn't be necessary, though it seems this is a question I should put to
> the others.
>> In the particular example we were using, the wording itself was the
>> essence of the proposal under discussion (i.e. mission statement,
>> V-M-A wording), where we were already agreed on the content, but not
>> on how that content should be worded, and hence a lot of discussion
>> was about trialling out different wordings, reverting, no xxx's
>> version sounded better (what was it
>> again?) etc etc.. So there are cases where tracking would be very
>> useful (indeed we subsequently moved the discussion to a wiki) -
>> however, I suspect this is more an exception than a rule, so at this
>> stage I leave the question open as to whether tracking is necessary or
>> not (I suspect desirable as an option, but not necessary).
>
> I can see that it might be useful in a few cases, however as you say, I
> think this is a rare and particular kind of decision, not one that comes up
> in most decisions.
>
> I think that for this sort of proposal, I might well use a collaborative
> document writing system that can save revisions, such as google docs, or
> lopad, or a wiki, etc. and then link to whatever tool I was using from my
> proposal in Econsensus. I think that your moving the practical
> implementation of this kind of task to a wiki makes a lot of sense with the
> level of functionality we have in Econsensus right now, and just leaving the
> discussion of the task in Econsensus.
>
> There's always a tension between replicating functionality from other tools
> in a new tool, or leaving them separate and using both. I can still see
> potential reasons for including this functionality in Econsensus, to help
> bigger groups track who is changing what when, and it feels like as the
> project gets bigger and goes on for more time, we are starting to be more
> shrewd about adding more time and functionality to the project!
>
>
>> Given my renewed understanding of how the software is supposed to
>> work, I am going to try to get everyone to use it again, so hopefully
>> we'll be able to give you more useful feedback in the future.
>>
>> Thanks for the clarification. All the best.
>>
>> Francois
>
> That's great to hear, thanks Francois!
>
> If any of what I'm saying still doesn't make sense then if you'd be up for
> scheduling a call sometime when you can walk me through the system that
> would be great. Alternatively, I can create demonstration items relating to
> what I'm talking about in our public Sandbox system for you to see and
> comment on.
>
> cheers,
> Tom.
>
> --
> Tom Lord | (to...@aptivate.org)
>
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967838 Future Business,
> Cambridge City FC, Milton Road, Cambridge CB4 1UY
>
> Aptivate is a not-for-profit company registered in England and Wales with
> company number 04980791.
>
--
Tom Lord | (to...@aptivate.org)
Aptivate | http://www.aptivate.org | Phone: +44 1223 967838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
Tom Lord | (to...@aptivate.org)
Aptivate | http://www.aptivate.org | Phone: +44 1223 967838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
to...@aptivate.org
Jan 12, 2013, 12:43:38 PM1/12/13
to econsens...@googlegroups.com
Thanks again Francois - I'm about to go away for a week so can reply more
fully when back. Some quick points in a messy, top-posted fashion(!) :
- Nate can probably explain our use of "danger". We don't mean "a project
is in danger", rather, it usually means "if we adopted this decision, I
think there would be a danger to the organisation". It would be unlikely
that we would agree to a proposal, operational or policy, with someone
shouting "danger!". E.g. someone could want to spend more money than we
have on some new equipment. Or we could be talking about a policy that
would take up too much of our time in admin to do enough work to keep us
afloat.
- Sometimes, in groups I have worked, it is important to record concerns
alongside the decision that is passed. In my experience, it is not always
the case that a proposal is modified to resolve all concerns (although I
would expect all "danger" or "block" or whatever to be resolved). So, in
some groups, proposals can go ahead with concerns, AND it is important
that it is noted that there were concerns. So that's the thinking behind
keeping the older feedback in there.
- We use Econsensus for all our decisions, policy and operational. We have
noted the need to distinguish between the two, AND it hasn't been so much
of an issue that we have fixed it yet. We find we spend more time making
decisions than reviewing them!
If I get another month of work on the project this year, I imagine we will
get onto another major feature which is "tagging" for decisions. This
would allow an organisation to flag decisions as being members of any
user-defined groups, like "policy", "operational", "financial", "Cambridge
office", or "Project X working group", etc. It would be very fluid - we
would not e.g. force there to be two types of decision - operations and
policy - although I am sure lots of groups might find that useful.
So I understand what you are saying about the need for more review-related
functionality like more dates and ongoing recording of concerns etc. AND I
think we can just make that kind of functionality generically available
for all decisions and let users defined their own types, rather than
trying to force a couple of pre-defined types of decision. As you have
noted in discussion of the terms used for feedback, anything that is fixed
runs the risk of putting people off :-)
Ok, look forward to corresponding when I'm back.
cheers!
Tom.
> Hi Tom
>
> Many thanks for your quick response - unfortunately I cannot match that
> speed, but ...
>
> There is not much for me to add or comment, except to answer some of your
> questions.
>
> Thanks for the econsensusdiscuss address, I think I just copied and pasted
> from an old email, not realising it had changed. Yes I tried just
> entering
> econsensus.org and it just takes me to the login page, presumably using my
> cache for the organisation. So that's fine. Thanks for explaining and
> removing the admin, again that's clear and fine.
>
> OK, I have not checked with the others to see if they got a new proposal
> notification email, I didn't, but from what you say I now understand why.
> After their having received 70 or so emails, even if I asked the others
> it's
> unlikely I'd get a clear answer, so I'll just assume for now that works as
> you say. Personally I do prefer to receive notices of my own stuff too,
> so
> that I don't have gaps in my email folder records and I can confirm what
> everyone else got, however it's not that important, possibly something to
> go
> in personal settings if it's easy to do, otherwise leave it as it is.
>
> I now understand the logic behind the default watch being turned on, and
> having heard your argument I agree it should remain that way, it should
> remain opt out as now, not opt in. The only caveat possibly the one you
> suggested of minor edits, but ....... ? Maybe the admin only should have
> the facility of turning the broadcast off at his/her discretion, e.g. when
> doing maintenance work. I must admit, doing what I did, transfer decision
> log from one system to econsensus was a one-off event, so this plethora of
> emails issue is unlikely to happen again.
>
> Great to have the tracking action items, though this raises another issue
> regarding policy vs operations, which may shed light in our different
> uses.
> Unfortunately I can't access the original general econsensus sample, but
> if
> I remember the examples correctly they had to do with things like buying a
> new coffee machine or organising a night out or similar. These would be
> what we would call operational matters. Sociocracy distinguishes between
> operations and policy. Operations tend to have actions with people
> leading
> them by a certain deadline, and once complete, that's it, they are done
> (with a possible evaluation). Policy decisions, however, apply to
> principles or rules or organisational design features which are always
> present, they are never "done" and finished with (unless abolished), but
> in
> the case of sociocracy they periodically have to be reviewed, i.e.
> measured
> and updated according to the outside realities to ensure they still help
> the
> cirle (group) achieve its aims. At the moment Sociocracy UK are using
> econsensus, perhaps wrongly, only for our POLICY decisions. In the USA
> sociocracy is referred to as dynamic governance, referring to the ever
> changing dynamic nature of policies through cybernetic feedback loops.
> This
> is why for us (at least on the policy making side) the "term" (which can
> either be the expiry or the review date, or also time frequency) and the
> measurement (the criteria against which a policy is to be evaluated in
> order
> to improve it), hence my request specifically for frequency and
> measurement
> boxes.
>
> That is also why I specifically wanted a Last reviewed (when it was last
> reviewed) and a Next review date (i.e. when is it next to be reviewed),
> with a particular emphasis in the list form on the Next review being one
> of
> the two dates showing (that's the one we have to keep a particular eye on,
> checking which policy is next in line for review). I have no objection to
> there being a fifth date to maintain an expiry date, though that is less
> important to us.
>
> Once a policy decision is made in sociocracy it is not necessary to record
> all the concern and objections that existed before consent, as the
> proposal
> (policy) would have been amended to take all those concerns and especially
> objections into account. In other words once a policy is consented to we
> only need to see the result, the policy, not the process. However, as the
> policy is played out it would be good to be able to record new
> (unforeseen)
> issues (new concerns) which arise from the policy and which need to be
> considered when it is next reviewed. This whole approach enables a sort
> of
> flexible (dynamic) good enough for now attitude where decisions can always
> be reviewed, even tested out (learning organisation), as there will always
> be an opportunity to revise in light of external realities later on, so
> not
> set in stone. Hence my request to be able to separate "feedback" BEFORE a
> decision is made and that AFTER the decision. What's before is not really
> relevant anymore, because it's been built into the decision, what comes
> after is crucial in terms of developing, amending etc the decision in the
> future at review time (or earlier if urgent). I suppose your suggestion
> of
> old and current with option of only seeing current would do the trick.
>
> Regarding the labels, I'm not fussy about the order of 3 and 4 (concern
> and
> objection), and if we were to have a sixth field then we could have keep
> the
> comments, but individual labelling of feedback is fields would probably
> make
> the software applicable to more organisations.
>
> However, thinking about the "danger" label, it occurs to me this is again
> a
> more Operational concept, eg when a project is in danger of not meeting a
> deadline. And it strikes me more and more that the way econsensus is
> constructed, including your comments, is far more "operational" (which can
> include development, projects and other forms of actions). This possibly
> explains why the others were having difficulty using the software, indeed
> it's making me re-think whether we should actually use it for our policy
> making, or should there be two versions of it, or two sides to it ?????
> I
> don't know. Anyway some food for thought there.
>
> Anyway thank you for your support and interest.
>
> Best regards
>
> Francois
> the discussion list from openconse...@googlegroups.com to
> econsens...@googlegroups.com .
>
> Apologies for any confusion - we have been standardising the name of the
> application to "Econsensus". A few months after choosing openconsent, we
> found a piece of medical consent software by the same name, so we
> switched,
> and it has been a long effort to stamp out all the remaining
> "openconsent"s!
>
> I've tweaked the body text of your email to remove reference to specific
> user login details - in general I think it's best practice to never put
> these on public email lists :-)
>
>> Sorry for not responding sooner. You have to bear in mind that we're
>> a very part-time network, we meet once a month and spend half our time
>> trying to remember what we did the previous month. Well, it's not
>> that bad, but there is a difference in pacing in that what we do in a
>> year is probably what you do in a week. That gives a slightly
>> different perspective on the software and speed of action.
>
> Not at all! I'm always happy to hear from you whenever, and discussing
> aspects of Econsensus is always a fresh and current point of interest for
> me
> :-) Thanks so much for taking the time to point out so many useful
> feature
> requests and notes on the system, it's really helpful for us. You have
> although everyone else will. This is by design - within Aptivate I think
fully when back. Some quick points in a messy, top-posted fashion(!) :
- Nate can probably explain our use of "danger". We don't mean "a project
is in danger", rather, it usually means "if we adopted this decision, I
think there would be a danger to the organisation". It would be unlikely
that we would agree to a proposal, operational or policy, with someone
shouting "danger!". E.g. someone could want to spend more money than we
have on some new equipment. Or we could be talking about a policy that
would take up too much of our time in admin to do enough work to keep us
afloat.
- Sometimes, in groups I have worked, it is important to record concerns
alongside the decision that is passed. In my experience, it is not always
the case that a proposal is modified to resolve all concerns (although I
would expect all "danger" or "block" or whatever to be resolved). So, in
some groups, proposals can go ahead with concerns, AND it is important
that it is noted that there were concerns. So that's the thinking behind
keeping the older feedback in there.
- We use Econsensus for all our decisions, policy and operational. We have
noted the need to distinguish between the two, AND it hasn't been so much
of an issue that we have fixed it yet. We find we spend more time making
decisions than reviewing them!
If I get another month of work on the project this year, I imagine we will
get onto another major feature which is "tagging" for decisions. This
would allow an organisation to flag decisions as being members of any
user-defined groups, like "policy", "operational", "financial", "Cambridge
office", or "Project X working group", etc. It would be very fluid - we
would not e.g. force there to be two types of decision - operations and
policy - although I am sure lots of groups might find that useful.
So I understand what you are saying about the need for more review-related
functionality like more dates and ongoing recording of concerns etc. AND I
think we can just make that kind of functionality generically available
for all decisions and let users defined their own types, rather than
trying to force a couple of pre-defined types of decision. As you have
noted in discussion of the terms used for feedback, anything that is fixed
runs the risk of putting people off :-)
Ok, look forward to corresponding when I'm back.
cheers!
Tom.
> Hi Tom
>
> Many thanks for your quick response - unfortunately I cannot match that
> speed, but ...
>
> There is not much for me to add or comment, except to answer some of your
> questions.
>
> Thanks for the econsensusdiscuss address, I think I just copied and pasted
> from an old email, not realising it had changed. Yes I tried just
> entering
> econsensus.org and it just takes me to the login page, presumably using my
> cache for the organisation. So that's fine. Thanks for explaining and
> removing the admin, again that's clear and fine.
>
> OK, I have not checked with the others to see if they got a new proposal
> notification email, I didn't, but from what you say I now understand why.
> After their having received 70 or so emails, even if I asked the others
> it's
> unlikely I'd get a clear answer, so I'll just assume for now that works as
> you say. Personally I do prefer to receive notices of my own stuff too,
> so
> that I don't have gaps in my email folder records and I can confirm what
> everyone else got, however it's not that important, possibly something to
> go
> in personal settings if it's easy to do, otherwise leave it as it is.
>
> I now understand the logic behind the default watch being turned on, and
> having heard your argument I agree it should remain that way, it should
> remain opt out as now, not opt in. The only caveat possibly the one you
> suggested of minor edits, but ....... ? Maybe the admin only should have
> the facility of turning the broadcast off at his/her discretion, e.g. when
> doing maintenance work. I must admit, doing what I did, transfer decision
> log from one system to econsensus was a one-off event, so this plethora of
> emails issue is unlikely to happen again.
>
> Great to have the tracking action items, though this raises another issue
> regarding policy vs operations, which may shed light in our different
> uses.
> Unfortunately I can't access the original general econsensus sample, but
> if
> I remember the examples correctly they had to do with things like buying a
> new coffee machine or organising a night out or similar. These would be
> what we would call operational matters. Sociocracy distinguishes between
> operations and policy. Operations tend to have actions with people
> leading
> them by a certain deadline, and once complete, that's it, they are done
> (with a possible evaluation). Policy decisions, however, apply to
> principles or rules or organisational design features which are always
> present, they are never "done" and finished with (unless abolished), but
> in
> the case of sociocracy they periodically have to be reviewed, i.e.
> measured
> and updated according to the outside realities to ensure they still help
> the
> cirle (group) achieve its aims. At the moment Sociocracy UK are using
> econsensus, perhaps wrongly, only for our POLICY decisions. In the USA
> sociocracy is referred to as dynamic governance, referring to the ever
> changing dynamic nature of policies through cybernetic feedback loops.
> This
> is why for us (at least on the policy making side) the "term" (which can
> either be the expiry or the review date, or also time frequency) and the
> measurement (the criteria against which a policy is to be evaluated in
> order
> to improve it), hence my request specifically for frequency and
> measurement
> boxes.
>
> That is also why I specifically wanted a Last reviewed (when it was last
> reviewed) and a Next review date (i.e. when is it next to be reviewed),
> with a particular emphasis in the list form on the Next review being one
> of
> the two dates showing (that's the one we have to keep a particular eye on,
> checking which policy is next in line for review). I have no objection to
> there being a fifth date to maintain an expiry date, though that is less
> important to us.
>
> Once a policy decision is made in sociocracy it is not necessary to record
> all the concern and objections that existed before consent, as the
> proposal
> (policy) would have been amended to take all those concerns and especially
> objections into account. In other words once a policy is consented to we
> only need to see the result, the policy, not the process. However, as the
> policy is played out it would be good to be able to record new
> (unforeseen)
> issues (new concerns) which arise from the policy and which need to be
> considered when it is next reviewed. This whole approach enables a sort
> of
> flexible (dynamic) good enough for now attitude where decisions can always
> be reviewed, even tested out (learning organisation), as there will always
> be an opportunity to revise in light of external realities later on, so
> not
> set in stone. Hence my request to be able to separate "feedback" BEFORE a
> decision is made and that AFTER the decision. What's before is not really
> relevant anymore, because it's been built into the decision, what comes
> after is crucial in terms of developing, amending etc the decision in the
> future at review time (or earlier if urgent). I suppose your suggestion
> of
> old and current with option of only seeing current would do the trick.
>
> Regarding the labels, I'm not fussy about the order of 3 and 4 (concern
> and
> objection), and if we were to have a sixth field then we could have keep
> the
> comments, but individual labelling of feedback is fields would probably
> make
> the software applicable to more organisations.
>
> However, thinking about the "danger" label, it occurs to me this is again
> a
> more Operational concept, eg when a project is in danger of not meeting a
> deadline. And it strikes me more and more that the way econsensus is
> constructed, including your comments, is far more "operational" (which can
> include development, projects and other forms of actions). This possibly
> explains why the others were having difficulty using the software, indeed
> it's making me re-think whether we should actually use it for our policy
> making, or should there be two versions of it, or two sides to it ?????
> I
> don't know. Anyway some food for thought there.
>
> Anyway thank you for your support and interest.
>
> Best regards
>
> Francois
>
>
> -----Original Message-----
> From: Tom Lord [mailto:to...@aptivate.org]
> Sent: 10 January 2013 13:02
> To: f...@open2flow.co.uk
> Subject: Re: changes to Econsensus
>
> Hey Francois,
>
> Firstly, maybe you missed the email where we changed the email address for
>
> -----Original Message-----
> From: Tom Lord [mailto:to...@aptivate.org]
> Sent: 10 January 2013 13:02
> To: f...@open2flow.co.uk
> Subject: Re: changes to Econsensus
>
> Hey Francois,
>
> the discussion list from openconse...@googlegroups.com to
> econsens...@googlegroups.com .
>
> Apologies for any confusion - we have been standardising the name of the
> application to "Econsensus". A few months after choosing openconsent, we
> found a piece of medical consent software by the same name, so we
> switched,
> and it has been a long effort to stamp out all the remaining
> "openconsent"s!
>
> I've tweaked the body text of your email to remove reference to specific
> user login details - in general I think it's best practice to never put
> these on public email lists :-)
>
>> Sorry for not responding sooner. You have to bear in mind that we're
>> a very part-time network, we meet once a month and spend half our time
>> trying to remember what we did the previous month. Well, it's not
>> that bad, but there is a difference in pacing in that what we do in a
>> year is probably what you do in a week. That gives a slightly
>> different perspective on the software and speed of action.
>
> Not at all! I'm always happy to hear from you whenever, and discussing
> aspects of Econsensus is always a fresh and current point of interest for
> me
> :-) Thanks so much for taking the time to point out so many useful
> feature
> requests and notes on the system, it's really helpful for us. You have
Francois Knuchel
Jan 17, 2013, 7:08:10 PM1/17/13
to econsens...@googlegroups.com
Hi Tom
Just a few brief comments on your notes:
- Yes, I had understood 'danger' to denote what we call reasoned or
paramount objection and yes on second thoughts (or viewing) parts of the
program are more policy oriented. And yes, you're right concerns should be
noted. It would still be good, I think, to be able to see what's older and
what newer, so I think your suggestion of having older and current good.
Alternatively if the feedback comments were automatically date stamped, then
it would be easier to see what's what - ideally with the option of sorting
the feedback by date (forward or reverse chronological order).
- I didn't mean imply objections shouldn't be recorded, just that they
didn't have to be - but having already been written down by someone in the
feedback, it would be ridiculous not to include them.
- I agree having flexible user-determined ways of defining decision types,
each with the option of their circle decisions and members. Which leads to
an aspect we haven't talked about yet, but which will be very important for
organisation with more than one circle. The ability of each to have their
own circle account (with proposals and decisions) while at same time being
linked to other circles of the same organisation. Some members (eg
representatives) would be members of more than one circle and would need to
be able to cross link, ......... (?). But maybe that's for another day.
- I am looking at econsensus not purely from a point of view of what would
be useful for Sociocracy UK, but also from a commercial point of view, what
I think would be needed to make the application sellable (e.g. recommend to
a client who was implementing sociocracy). From that perspective having
user-defined options rather than predetermined patterns gives you far more
flexibility in commercial terms, so I completely agree that is a better way
forward where it is technically possible.
All the best for now. Regards
Francois
--
Just a few brief comments on your notes:
- Yes, I had understood 'danger' to denote what we call reasoned or
paramount objection and yes on second thoughts (or viewing) parts of the
program are more policy oriented. And yes, you're right concerns should be
noted. It would still be good, I think, to be able to see what's older and
what newer, so I think your suggestion of having older and current good.
Alternatively if the feedback comments were automatically date stamped, then
it would be easier to see what's what - ideally with the option of sorting
the feedback by date (forward or reverse chronological order).
- I didn't mean imply objections shouldn't be recorded, just that they
didn't have to be - but having already been written down by someone in the
feedback, it would be ridiculous not to include them.
- I agree having flexible user-determined ways of defining decision types,
each with the option of their circle decisions and members. Which leads to
an aspect we haven't talked about yet, but which will be very important for
organisation with more than one circle. The ability of each to have their
own circle account (with proposals and decisions) while at same time being
linked to other circles of the same organisation. Some members (eg
representatives) would be members of more than one circle and would need to
be able to cross link, ......... (?). But maybe that's for another day.
- I am looking at econsensus not purely from a point of view of what would
be useful for Sociocracy UK, but also from a commercial point of view, what
I think would be needed to make the application sellable (e.g. recommend to
a client who was implementing sociocracy). From that perspective having
user-defined options rather than predetermined patterns gives you far more
flexibility in commercial terms, so I completely agree that is a better way
forward where it is technically possible.
All the best for now. Regards
Francois
Francois Knuchel
May 4, 2013, 9:17:34 AM5/4/13
to econsens...@googlegroups.com, Martin Grimshaw, sue...@lifejourneys.co.uk, Nathaniel Whitestone
Hi Tom
Hope you're well. We haven't written for a while. That was partly because
I was sort of expecting a fuller reply from you to my last email after your
week away, and then I also forgot about it. However, I would like to
(re-)raise the following requests for econsensus. Could you let me know
which are easy to implement and when you could do that, and which are
complicated and I should sit on for the time being:
- Could the main Edit link be made a bit bigger or as a button, so it's more
obvious?
choose?
- When archiving there is a Date archived box. Can that be automated to when
it is actually archived?
- When changing status from proposal to decision, one has to do this in 2
steps, first change proposal to decision and save that, then go into Edit
mode again to add the relevant dates (causing yet another email to go out).
- Can the date labels be changed as follows:
- Decided: 'Decided'
- Effective: 'Effective / Last Reviewed' *
- Review: 'Next review' *
- Expiry: 'Expiry' (has this been removed? if so it's OK, we can
do without too)
- Can two more boxes be added in decision mode (ideally on right hand side)?
- 'Term / Review period' (text box, to enter frequency of review,
e.g. annually, bi-monthly......) *
Excerpt, Decided and Review, I wonder if it's possible to add the (new)
field 'Term/Review period' and then replace the 'Decided' field with the
'Effective/Last Reviewed' field? So it would then look like this: ID -
Excerpt - 'Term/Review period' - 'Effective/Last Reviewed' -
'Next Review' and maintain the ability to sort by dates as now. As I'm
adding a new field to the list, I don't want to take too much space away
from Excerpt, so is it possible to move the dates closer together out to the
right?
- Are you planning to date or reverse chronological order all the feedbacks?
- Is it possible to re-label the feedback types as follows (or enable user
definitions)
- Question = Question (same) 1
- Danger = Objection 4
- Concerns = Concern 3
- Consent = Consent (same) 5
- Comment = Reaction 2
(If there is scope for a 6th one, then 'Comment')
And to reorder them in the order number given above. Or make them user
determined?
I see you have made quite a few changes which I welcome, but I wonder how
easy it is going to be for users to custom make their list (as my request
above), or even at some point design their own lists like a database?
At the moment I maintain two lists of all our policy decisions, the
econsensus one and also just an ordinary spreadsheet. The spreadsheet has
the advantage of having key info, dates in a clear and data-sortable
overview, but has the disadvantage of not being to note down the policy
details, wordings, and concerns related to the decisions, nor the
possibility of linking it to the whole proposal and decision-making process
as in econsensus. However, keeping two systems up-to-date is cumbersome,
and is not sustainable, especially now that I am passing on my
secretarial/logbook keeping role to someone else. At some point we, and the
new person, will decide to drop one of the two systems, and I fear that
unless we can bring econsensus up to speed and user-friendly, as per my
suggestions above, then econsensus could possibly go (though that won't be
my decision to make any more). The above requests are not comprehensive,
but would be a good starting point.
You may also decide that I am putting too many requests or demands to be
worth your while, which is fine too, just let me know, I really appreciate
the time and effort you have put into this and for having had the
opportunity to try out something like this.
Looking forward to your input, thank you.
Kind regards
Francois
-----Original Message-----
From: econsens...@googlegroups.com
[mailto:econsens...@googlegroups.com] On Behalf Of to...@aptivate.org
Sent: 12 January 2013 17:44
To: econsens...@googlegroups.com
Subject: RE: changes to Econsensus
--
Hope you're well. We haven't written for a while. That was partly because
I was sort of expecting a fuller reply from you to my last email after your
week away, and then I also forgot about it. However, I would like to
(re-)raise the following requests for econsensus. Could you let me know
which are easy to implement and when you could do that, and which are
complicated and I should sit on for the time being:
- Could the main Edit link be made a bit bigger or as a button, so it's more
obvious?
- When creating a new proposal there is no longer any notification going out
to all by email saying that someone has created a new proposal. Can that be
re-instated, or can it be introduced as an option for the proposer to
to all by email saying that someone has created a new proposal. Can that be
choose?
- When archiving there is a Date archived box. Can that be automated to when
it is actually archived?
steps, first change proposal to decision and save that, then go into Edit
mode again to add the relevant dates (causing yet another email to go out).
I'm not sure what to suggest, but it seems to me there should be a more
ceremonious way of transforming a proposal into a decision where all the
relevant dates can be entered at the same time in 1 step.
ceremonious way of transforming a proposal into a decision where all the
- Can the date labels be changed as follows:
- Effective: 'Effective / Last Reviewed' *
- Review: 'Next review' *
- Expiry: 'Expiry' (has this been removed? if so it's OK, we can
do without too)
- Can two more boxes be added in decision mode (ideally on right hand side)?
- 'Term / Review period' (text box, to enter frequency of review,
e.g. annually, bi-monthly......) *
- 'Measurement' (text box, to enter how a policy is going to be
measured)
* In the Decisions Made table view mode listing all the decision under ID,
measured)
Excerpt, Decided and Review, I wonder if it's possible to add the (new)
field 'Term/Review period' and then replace the 'Decided' field with the
'Effective/Last Reviewed' field? So it would then look like this: ID -
Excerpt - 'Term/Review period' - 'Effective/Last Reviewed' -
'Next Review' and maintain the ability to sort by dates as now. As I'm
adding a new field to the list, I don't want to take too much space away
from Excerpt, so is it possible to move the dates closer together out to the
right?
- Are you planning to date or reverse chronological order all the feedbacks?
- Is it possible to re-label the feedback types as follows (or enable user
definitions)
- Question = Question (same) 1
- Danger = Objection 4
- Concerns = Concern 3
- Consent = Consent (same) 5
- Comment = Reaction 2
And to reorder them in the order number given above. Or make them user
determined?
I see you have made quite a few changes which I welcome, but I wonder how
easy it is going to be for users to custom make their list (as my request
above), or even at some point design their own lists like a database?
At the moment I maintain two lists of all our policy decisions, the
econsensus one and also just an ordinary spreadsheet. The spreadsheet has
the advantage of having key info, dates in a clear and data-sortable
overview, but has the disadvantage of not being to note down the policy
details, wordings, and concerns related to the decisions, nor the
possibility of linking it to the whole proposal and decision-making process
as in econsensus. However, keeping two systems up-to-date is cumbersome,
and is not sustainable, especially now that I am passing on my
secretarial/logbook keeping role to someone else. At some point we, and the
new person, will decide to drop one of the two systems, and I fear that
unless we can bring econsensus up to speed and user-friendly, as per my
suggestions above, then econsensus could possibly go (though that won't be
my decision to make any more). The above requests are not comprehensive,
but would be a good starting point.
You may also decide that I am putting too many requests or demands to be
worth your while, which is fine too, just let me know, I really appreciate
the time and effort you have put into this and for having had the
opportunity to try out something like this.
Looking forward to your input, thank you.
Kind regards
Francois
-----Original Message-----
From: econsens...@googlegroups.com
[mailto:econsens...@googlegroups.com] On Behalf Of to...@aptivate.org
Sent: 12 January 2013 17:44
To: econsens...@googlegroups.com
Subject: RE: changes to Econsensus
Tom Lord
May 7, 2013, 8:27:54 AM5/7/13
to econsens...@googlegroups.com, Francois Knuchel, Martin Grimshaw, sue...@lifejourneys.co.uk, Nathaniel Whitestone
Hi Francois! Thanks for the prod, I hadn't realised you still had
questions outstanding, my apologies; we've been pretty hectic this year
up until now and I have been pulled away onto various projects.
In general:
- if it's easier to go through this by phone or skype then please just
suggest a time. I'm aware that these email conversations between us end
up as somewhat epics, thanks again for taking the time!
- we have been finding it hard to allocate as much time to Econsensus as
I would like, as it is all unpaid at the moment. We are currently
focusing our efforts on making the site as user-friendly as possible for
new organisations to sign up to. The new changes we made, to allow
multiple orgs to be hosted on the same instance, resulted in quite a few
usability issues that we are still working through, and I'm hoping we
can break out of this in the next month or so and start addressing other
things.
- we really welcome feedback about what you would find useful, and we
will do our best to discuss and incorporate them, along with the rest of
our priorities.
- We are by far the biggest users of Econsensus so we are generating a
bunch of features we think are high priority. There is a bunch of stuff
where we are finding an issue with the way it works at the moment now
that we are using it pretty heavily. This is mainly around the process
of generating and resolving proposals, without necessarily having a
facilitator, or an intermittent or ad-hoc facilitator. Proposals are
stacking up and we need a way to reduce the backlog and also address
people's concerns that if they lose track of the flood of suggestions in
the proposals pile, things might happen before they have considered
them. This is relatively easily addressed in a meeting, interesting to
consider online in an asynchronous manner.
- If you want something sooner than we are planning to address it, ways
to short-circuit the process could be to see if you can find someone who
can contribute to the codebase, or to discuss paying for its development
(which I appreciate may not be an option), or convince us that if it
doesn't exist, you can't continue to use Econsensus (as you may be doing :-)
On 04/05/13 14:17, Francois Knuchel wrote:
> Hi Tom
>
and shouldn't take long. I hope it will be a few weeks at most!
> - When creating a new proposal there is no longer any notification going out
> to all by email saying that someone has created a new proposal. Can that be
> re-instated, or can it be introduced as an option for the proposer to
> choose?
Ok, this is interesting and I'd like to investigate. Email notifications
do get sent out for new proposals, or at least they should. Are you
saying that you get email notifications for everything else, but not
proposals?
> - When archiving there is a Date archived box. Can that be automated
to when
> it is actually archived?
That would be nice, and yes we have a bunch of task cards for automating
/ adding some dates of changes to things. I will flag that this is
something you would like. In general we are not focusing much on the
archives. However as one of our few users other than ourselves, I would
like to take your feedback into account.
In some of the stuff we want to address, for our own perceptions of
what's going to make Econsensus work under heavy use, is the idea that
proposals probably shouldn't hang around for months. This means that
it's probably going to be more important to be able to easily move
things from e.g. Decision to Proposal and back again. I think that this
will make it more useful to see a history of 'moves' between statuses,
and at that point being able to see the dates that things changed status
will be important. So, I think this kind of thing is coming, and I can't
say when at the moment.
> - When changing status from proposal to decision, one has to do this in 2
> steps, first change proposal to decision and save that, then go into Edit
> mode again to add the relevant dates (causing yet another email to go out).
> I'm not sure what to suggest, but it seems to me there should be a more
> ceremonious way of transforming a proposal into a decision where all the
> relevant dates can be entered at the same time in 1 step.
I see, yes, double emails are a bit of a pain aren't they. We removed
some of them, thanks for pointing out this one.
I think that when changing the status of something, e.g. from proposal
to decision, we could look at making more fields available as soon as
the status changes. I'll talk to the folks here about this and see if
this is easy. It does tie in to this theme about changing statuses more
easily.
> - Can the date labels be changed as follows:
> - Decided: 'Decided'
> - Effective: 'Effective / Last Reviewed' *
> - Review: 'Next review' *
> - Expiry: 'Expiry' (has this been removed? if so it's OK, we can
> do without too)
I can see the sense in that, and it doesn't sound too controversial.
I'll ask our users here, and I think we can do that easily and soon, as
long as no-one objects.
> - Can two more boxes be added in decision mode (ideally on right hand side)?
> - 'Term / Review period' (text box, to enter frequency of review,
> e.g. annually, bi-monthly......) *
> - 'Measurement' (text box, to enter how a policy is going to be
> measured)
I can see that kind of thing is valuable when considering decisions over
the long term.
How about a "Review notes" text box, that could incorporate both of
these things in free text (and maybe e.g. also the results of various
reviews)? (although I see your point below...)
> * In the Decisions Made table view mode listing all the decision under ID,
> Excerpt, Decided and Review, I wonder if it's possible to add the (new)
> field 'Term/Review period' and then replace the 'Decided' field with the
> 'Effective/Last Reviewed' field? So it would then look like this: ID -
> Excerpt - 'Term/Review period' - 'Effective/Last Reviewed' -
> 'Next Review' and maintain the ability to sort by dates as now. As I'm
> adding a new field to the list, I don't want to take too much space away
> from Excerpt, so is it possible to move the dates closer together out to the
> right?
Ah I see, you really want this review period don't you :-) Can you
explain more how critical it is to you to see this particular info in
this table? I think the "review notes" as above would be relatively
easy, and I think that this sounds a bit more work, so if I can get away
with the above then I'd like to... will be good to understand your use
case though.
I agree generally that the table views could have more useful info /
dates in than they do now, this will be easier when we have actually
added more dates to the models in general.
> - Are you planning to date or reverse chronological order all the feedbacks?
Again, auto-dating things is one of those things that is likely to be
implemented in the medium term, and at the moment I can't say when that
would be!
I'll see if people are up for reversing the order here. I know we did
discuss it. I imagine it's pretty easy.
> - Is it possible to re-label the feedback types as follows (or enable user
> definitions)
> - Question = Question (same) 1
> - Danger = Objection 4
> - Concerns = Concern 3
> - Consent = Consent (same) 5
> - Comment = Reaction 2
> (If there is scope for a 6th one, then 'Comment')
> And to reorder them in the order number given above. Or make them user
> determined?
Fully user-determined feedback is apparently hard work. I will ask again
about what our options are here - I imagine that if we keep the same
number but allow renaming of them, which is what it sounds like you are
talking about, it is less work. Still some work but not pulling out the
guts of the feedback system.
I'm not sure if we want to change the names globally. I hear that you
do! Let's see what the answer is on the cost of just renaming the
existing 5 feedbacks.
I agree that we can re-order them into some kind of sensible order. That
sounds quick. I will check, and if so then we can get that done soon.
> I see you have made quite a few changes which I welcome, but I wonder how
> easy it is going to be for users to custom make their list (as my request
> above), or even at some point design their own lists like a database?
You mean like add custom fields to proposals or decisions, and choose
which fields are shown in the table views? That has crossed my mind.
It's a bunch of work, a mini-project in itself, I can imagine
organisations would find it useful, and I can imagine that it would be
re-usable in lots of other projects. I don't think it will happen soon
because of the amount of work I think it would take. I will talk to
folks here about it though and get more info.
> At the moment I maintain two lists of all our policy decisions, the
> econsensus one and also just an ordinary spreadsheet. The spreadsheet has
> the advantage of having key info, dates in a clear and data-sortable
> overview, but has the disadvantage of not being to note down the policy
> details, wordings, and concerns related to the decisions, nor the
> possibility of linking it to the whole proposal and decision-making process
> as in econsensus. However, keeping two systems up-to-date is cumbersome,
> and is not sustainable, especially now that I am passing on my
> secretarial/logbook keeping role to someone else. At some point we, and the
> new person, will decide to drop one of the two systems, and I fear that
> unless we can bring econsensus up to speed and user-friendly, as per my
> suggestions above, then econsensus could possibly go (though that won't be
> my decision to make any more). The above requests are not comprehensive,
> but would be a good starting point.
Sure, all makes sense. Can you clarify the extra fields in the
spreadsheet that you use? Is it just the review period, or anything else?
> You may also decide that I am putting too many requests or demands to be
> worth your while, which is fine too, just let me know, I really appreciate
> the time and effort you have put into this and for having had the
> opportunity to try out something like this.
Not at all, I really appreciate that you want to work with us and give
us feedback on this tool that we are very interested in developing for
not-just-us! I will do my best to be clear about what I think we can and
can't do anytime soon with current resources. Please continue to feel
free to ask / comment / demand, it's very useful to me to help me think
about this, even if we can't achieve everything.
all the best,
questions outstanding, my apologies; we've been pretty hectic this year
up until now and I have been pulled away onto various projects.
In general:
- if it's easier to go through this by phone or skype then please just
suggest a time. I'm aware that these email conversations between us end
up as somewhat epics, thanks again for taking the time!
- we have been finding it hard to allocate as much time to Econsensus as
I would like, as it is all unpaid at the moment. We are currently
focusing our efforts on making the site as user-friendly as possible for
new organisations to sign up to. The new changes we made, to allow
multiple orgs to be hosted on the same instance, resulted in quite a few
usability issues that we are still working through, and I'm hoping we
can break out of this in the next month or so and start addressing other
things.
- we really welcome feedback about what you would find useful, and we
will do our best to discuss and incorporate them, along with the rest of
our priorities.
- We are by far the biggest users of Econsensus so we are generating a
bunch of features we think are high priority. There is a bunch of stuff
where we are finding an issue with the way it works at the moment now
that we are using it pretty heavily. This is mainly around the process
of generating and resolving proposals, without necessarily having a
facilitator, or an intermittent or ad-hoc facilitator. Proposals are
stacking up and we need a way to reduce the backlog and also address
people's concerns that if they lose track of the flood of suggestions in
the proposals pile, things might happen before they have considered
them. This is relatively easily addressed in a meeting, interesting to
consider online in an asynchronous manner.
- If you want something sooner than we are planning to address it, ways
to short-circuit the process could be to see if you can find someone who
can contribute to the codebase, or to discuss paying for its development
(which I appreciate may not be an option), or convince us that if it
doesn't exist, you can't continue to use Econsensus (as you may be doing :-)
On 04/05/13 14:17, Francois Knuchel wrote:
> Hi Tom
>
> Hope you're well. We haven't written for a while. That was partly because
> I was sort of expecting a fuller reply from you to my last email after your
> week away, and then I also forgot about it. However, I would like to
> (re-)raise the following requests for econsensus. Could you let me know
> which are easy to implement and when you could do that, and which are
> complicated and I should sit on for the time being:
>
> - Could the main Edit link be made a bit bigger or as a button, so it's more
> obvious?
We sure can. I remember you saying that. That is in the current backlog
> I was sort of expecting a fuller reply from you to my last email after your
> week away, and then I also forgot about it. However, I would like to
> (re-)raise the following requests for econsensus. Could you let me know
> which are easy to implement and when you could do that, and which are
> complicated and I should sit on for the time being:
>
> - Could the main Edit link be made a bit bigger or as a button, so it's more
> obvious?
and shouldn't take long. I hope it will be a few weeks at most!
> - When creating a new proposal there is no longer any notification going out
> to all by email saying that someone has created a new proposal. Can that be
> re-instated, or can it be introduced as an option for the proposer to
> choose?
do get sent out for new proposals, or at least they should. Are you
saying that you get email notifications for everything else, but not
proposals?
> - When archiving there is a Date archived box. Can that be automated
to when
> it is actually archived?
/ adding some dates of changes to things. I will flag that this is
something you would like. In general we are not focusing much on the
archives. However as one of our few users other than ourselves, I would
like to take your feedback into account.
In some of the stuff we want to address, for our own perceptions of
what's going to make Econsensus work under heavy use, is the idea that
proposals probably shouldn't hang around for months. This means that
it's probably going to be more important to be able to easily move
things from e.g. Decision to Proposal and back again. I think that this
will make it more useful to see a history of 'moves' between statuses,
and at that point being able to see the dates that things changed status
will be important. So, I think this kind of thing is coming, and I can't
say when at the moment.
> - When changing status from proposal to decision, one has to do this in 2
> steps, first change proposal to decision and save that, then go into Edit
> mode again to add the relevant dates (causing yet another email to go out).
> I'm not sure what to suggest, but it seems to me there should be a more
> ceremonious way of transforming a proposal into a decision where all the
> relevant dates can be entered at the same time in 1 step.
some of them, thanks for pointing out this one.
I think that when changing the status of something, e.g. from proposal
to decision, we could look at making more fields available as soon as
the status changes. I'll talk to the folks here about this and see if
this is easy. It does tie in to this theme about changing statuses more
easily.
> - Can the date labels be changed as follows:
> - Decided: 'Decided'
> - Effective: 'Effective / Last Reviewed' *
> - Review: 'Next review' *
> - Expiry: 'Expiry' (has this been removed? if so it's OK, we can
> do without too)
I'll ask our users here, and I think we can do that easily and soon, as
long as no-one objects.
> - Can two more boxes be added in decision mode (ideally on right hand side)?
> - 'Term / Review period' (text box, to enter frequency of review,
> e.g. annually, bi-monthly......) *
> - 'Measurement' (text box, to enter how a policy is going to be
> measured)
the long term.
How about a "Review notes" text box, that could incorporate both of
these things in free text (and maybe e.g. also the results of various
reviews)? (although I see your point below...)
> * In the Decisions Made table view mode listing all the decision under ID,
> Excerpt, Decided and Review, I wonder if it's possible to add the (new)
> field 'Term/Review period' and then replace the 'Decided' field with the
> 'Effective/Last Reviewed' field? So it would then look like this: ID -
> Excerpt - 'Term/Review period' - 'Effective/Last Reviewed' -
> 'Next Review' and maintain the ability to sort by dates as now. As I'm
> adding a new field to the list, I don't want to take too much space away
> from Excerpt, so is it possible to move the dates closer together out to the
> right?
explain more how critical it is to you to see this particular info in
this table? I think the "review notes" as above would be relatively
easy, and I think that this sounds a bit more work, so if I can get away
with the above then I'd like to... will be good to understand your use
case though.
I agree generally that the table views could have more useful info /
dates in than they do now, this will be easier when we have actually
added more dates to the models in general.
> - Are you planning to date or reverse chronological order all the feedbacks?
implemented in the medium term, and at the moment I can't say when that
would be!
I'll see if people are up for reversing the order here. I know we did
discuss it. I imagine it's pretty easy.
> - Is it possible to re-label the feedback types as follows (or enable user
> definitions)
> - Question = Question (same) 1
> - Danger = Objection 4
> - Concerns = Concern 3
> - Consent = Consent (same) 5
> - Comment = Reaction 2
> (If there is scope for a 6th one, then 'Comment')
> And to reorder them in the order number given above. Or make them user
> determined?
about what our options are here - I imagine that if we keep the same
number but allow renaming of them, which is what it sounds like you are
talking about, it is less work. Still some work but not pulling out the
guts of the feedback system.
I'm not sure if we want to change the names globally. I hear that you
do! Let's see what the answer is on the cost of just renaming the
existing 5 feedbacks.
I agree that we can re-order them into some kind of sensible order. That
sounds quick. I will check, and if so then we can get that done soon.
> I see you have made quite a few changes which I welcome, but I wonder how
> easy it is going to be for users to custom make their list (as my request
> above), or even at some point design their own lists like a database?
which fields are shown in the table views? That has crossed my mind.
It's a bunch of work, a mini-project in itself, I can imagine
organisations would find it useful, and I can imagine that it would be
re-usable in lots of other projects. I don't think it will happen soon
because of the amount of work I think it would take. I will talk to
folks here about it though and get more info.
> At the moment I maintain two lists of all our policy decisions, the
> econsensus one and also just an ordinary spreadsheet. The spreadsheet has
> the advantage of having key info, dates in a clear and data-sortable
> overview, but has the disadvantage of not being to note down the policy
> details, wordings, and concerns related to the decisions, nor the
> possibility of linking it to the whole proposal and decision-making process
> as in econsensus. However, keeping two systems up-to-date is cumbersome,
> and is not sustainable, especially now that I am passing on my
> secretarial/logbook keeping role to someone else. At some point we, and the
> new person, will decide to drop one of the two systems, and I fear that
> unless we can bring econsensus up to speed and user-friendly, as per my
> suggestions above, then econsensus could possibly go (though that won't be
> my decision to make any more). The above requests are not comprehensive,
> but would be a good starting point.
spreadsheet that you use? Is it just the review period, or anything else?
> You may also decide that I am putting too many requests or demands to be
> worth your while, which is fine too, just let me know, I really appreciate
> the time and effort you have put into this and for having had the
> opportunity to try out something like this.
us feedback on this tool that we are very interested in developing for
not-just-us! I will do my best to be clear about what I think we can and
can't do anytime soon with current resources. Please continue to feel
free to ask / comment / demand, it's very useful to me to help me think
about this, even if we can't achieve everything.
all the best,
Reply all
Reply to author
Forward
0 new messages