Coder Social home page Coder Social logo

econsensus's Introduction

Econsensus

Econsensus is an open source web application tool for consensus decision-making within one or more organizations, used and written by Aptivate.

Send us an email at [email protected] to let us know you're interested in working on the project, and we'll be in touch to see how we can support you.

If you'd like to contribute to this project, please read the rest of this section, otherwise if you just want to install and try it out, skip to the next section.

If you'd like to contribute to this project, first of all welcome! Secondly, please follow the workflow below:

  • fork the repository on github into your own github account
  • follow the instructions below to install a development instance, but instead of cloning from the aptivate repository, clone from the 'develop' branch of your forked repository - always work on the develop branch because that's more up-to-date than master.
  • now create a branch of your local develop branch as follows:
$ git branch my_branch

and check it out:

$ git checkout my_branch

Please run the tests as you develop, and certainly before submitting your changes to us:

$ cd django/econsensus/econsensus
$ rm local_settings.py
$ ln -s local_settings.py.dev_fasttests local_settings.py
$ cd ..
$ ./manage.py test publicweb

Once you're done committing and all the tests are passing, push your branch to your account on github:

$ git push origin my_branch
  • find your branch my_branch on your github account and use the github button to submit a pull request to the aptivate develop branch
  • we'll get notified of your pull request and will be in touch asap

Thank you for your interest!

Install an instance

This is based on using Ubuntu >= 10.04, but should also work on Debian Squeeze.

First install the requirements:

$ sudo apt-get install git-core python-virtualenv python-pip sqlite3 \
      python-dev libxml2-dev libyaml-dev mysql-server mysql-client \
      libmysqlclient-dev build-essential libxslt1-dev mercurial

Then check out the code. For the latest stable code:

$ git clone https://github.com/aptivate/econsensus.git

For contributors, get the develop branch from your forked repository:

$ git clone https://github.com/my_user_account/econsensus.git -b develop

Then you should be able to do:

$ cd econsensus
$ deploy/bootstrap.py
$ deploy/tasks.py deploy:dev

This will create the virtualenv and install the python packages required, then create the database with an initial admin user for use of the django admin screens and a few other details (see the dye readme for more details). You should now be able to run the development server:

$ cd django/econsensus/
$ ./manage.py runserver

Use the instance

You should now be able to access the django admin screens at:

http://127.0.0.1:8000/admin/

using the admin user with username and password 'admin'. This password can be changed via the django admin screens (see User table).

You should also be able to access the application screens at:

http://127.0.0.1:8000/

which will show you the login screen, or allow you to "Sign up as a new member".

We suggest you begin by creating some users and organizations for your new econsensus instance. Start by signing up a new member by following the link on the login screen, log in and then create a new organization for that new member. Once you've done this, your new member can add other members to their organization because a creator of a new organization is automatically an admin level user of that organization. You can also repeat these steps to sign up more members and create organizations for them, or you can also create new organizations as an existing logged-in user.

Installing default help pages

You can install help pages for the benefit of your users by running

$ ./manage.py loaddata default_flatpages

The text of these pages can be modified (and pages added or removed) via the django admin screen. Pages are 'flatpage' instances, and their content is in Markdown format.

Important note on email notifications

Please note that the processes described above involve email interaction. An econsensus instance installed as above is not set up to send out actual emails, but will instead write emails out as text files into the directory specified by the EMAIL_FILE_PATH setting in local_settings.py. This email behaviour is controlled by the EMAIL_BACKEND setting also in local_settings.py.

Enabling search

If you are using the dev settings (as set up above) then whoosh is the search backend used. See the HAYSTACK_CONNECTIONS section of econsensus/local_settings.py.dev

All you need to do to have search actually be able to find the content is to run:

./manage.py update_index

This will create a directory called whoosh_index in django/econsensus/ that will contain the files required.

Versioning

We've decided to update the version number for every release, using the following pattern:

v[release number].[major functionality number].[deployment number]

So, v0.4.7 means "Deployment #7, working towards major functionality #5 (which happens to be Action Items), which is part of Release #1"

It's possible that some pieces of major functionality will overtake one-another in terms of completion time - in which case we'll re-number them.

If we get to a double digit, we just roll over, e.g. v0.4.12 .

When we update the version, we also create a bit of documentation on the "updates" flatpage to explain what's new.

econsensus's People

Contributors

aliceh75 avatar aptivate-server avatar birdsarah avatar bitterjug avatar daniell avatar dinaeliza avatar duckpants avatar foobacca avatar martinburchell avatar matthewsimpson avatar miaoshan avatar philmcmahon avatar rdn32 avatar samastur avatar skiold avatar stephenpaulger avatar tomd-aptivate avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

econsensus's Issues

Show list of users with current status (consented, blocking or none)

In Cambridge K1 we were discussing how we want to do consensus-based decision making. We want to facilitate online users (who may be nervous) to take part in the process. So the facilitator needs to know:

  • who has consented
  • who is blocking
  • who hasn't participated

In order for this to be generalised and for "consent" and "block" not to have magical hard-coded meanings, I propose that we add a per-organisation priority list of "special" states. For example, in K1 we might set this list to the following, in this order:

  • consent
  • danger (I wish we had "block")

Then, if a user has any "consent" feedback on the proposal, they are considered to be in the "consent" state (just for this proposal).

If they have no "consent" feedback, it looks for the next type, "danger" in our case, and if they have any of those, they are considered to be in the "danger" state.

If they have no "danger" feedback either, then it's run out of feedbacks to search, so they are in the "undecided" state.

If this proposal doesn't get any objections and nobody implements it first, I may do it myself for K1.

re-add the free text field for "people involved in the discussion" to Decisions

Think this should be a free text field, manually populated for now.

Future upgrade will be helper gadget e.g. "select people from list of people in organisation", or auto-complete would work better for orgs with a lot of people.

Could also have a helper area where it's possible to define "groups" of people e.g. Weekly Team Meeting 01/02/2003 which would resolve to a whole bunch of people.

It is possible to show people who have participated online as well - think this might need options to include or not as different orgs might have different requirements on this.

"this proposal needs input from ..." - select (multiple) key people

sometimes decisions affect certain people such that it doesn't make sense to take them without the active involvement of those people. It would be nice to be able to say within a proposal "this needs input from Jane and Freddy".

So, we need to

change the model to allow these relationships between people and decisions
change the UI to allow key people to be associated with decisions
display the key people to someone viewing the decision
for bonus points, send an email to Jane and Freddy to say "This proposal [link] needs your input!"

If we ever get into asynchronous decision making, this could prevent a decision going ahead without input from key people. We're not working on that right now though.

Changing a decision type while adding takes you to the wrong screen

Steps to reproduce:

  1. Click add decision
  2. While adding the decision, change the dropdown to make it a proposal
  3. Click Save
    Expected result: I'm on the Proposal List page and I can see my new Proposal
    Actual result: I'm on the Decision List page and I can't see my new Proposal because it's on the Proposal List page so I might get confused.

Lighten yellow borders around list items

Subjectively, I find the heavy yellow borders around each item visually jarring, they make lists difficult to read.

Lightening, e.g. from FFCC00 to FFEECC, makes them less intrusive. But I think the standard for lists is to have alternating light backgrounds (e.g. white and pale yellow) instead of heavy borders around them. Please would you consider something like that?

And a yellow pony. Please daddy, please!

Make emails easier to read

I notice that when a decision changes state, I get an email like this:

Hello from the lin-openconsent.aptivate.org OpenConsent server!
This is to let you know that the following item:
[blah blah blah five hundred words]
has changed status from "proposal" to "decision"

This email is difficult to parse. The most important information (what changed, and how) is buried at the bottom and is not visually recognisable.

I propose changing the second line to:

duckpants changed the status of this item from "proposal" to "decision":

followed by the proposal text.

cross-browser testing

IE 6 and 7 have issues

to fix IE 7, Steve suggests getting rid of "clear both" in styles.css in #id_description

seems to still work in FF and also IE

upgrade design of feedback interface

We could move the type of feedback to the end of the text box, so it doesn't take up as much vertical space. We could also put the user below that. So it would look something like this:

,---------------------------------------- ,
| I wonder if we have enough | QUESTION
|cash to do this at the mo? | User: Fred
'------------------------------------------'

Also, could we make the box scale to the size of the text in it? Maybe we'd need a maximum size, like 5 lines of text, before it got in the way of viewing the others. That leads me on to...

...Another step could be to make an option to show feedback as links in a table, or similar to how it is now with "View More" links. The full interface is maybe useful when taking minutes in real-time and writing different feedback down, so maybe we'd keep that available somehow; it wouldn't be the default. Links in a table might make it easier to view everything on one page.

Allow deleting feedback

It's important to be able to delete your own feedback, especially a consent (e.g. if someone edits the proposal and you can no longer agree to it).

Code review comments

Hi all,

I had a quick look at the OpenConsent code and I have a few suggestions:

In the global urls.py, urlpatterns is assigned and then appended to. A single assignment would work just as well.

The commented-out #url(r'^public/', include('openconsent.publicweb.urls')) could be removed.

What's the reason for all the decision_create_snippet_info dicts in urls.py? It seems to make sense to pass the template name into a view function, but why pass the queryset in? It might actually be wrong/out of date as it's effectively a global variable, but it's not immutable, so it might be evaluated once and cached, which would be wrong (not include new decisions).

list_detail and other function-based generic views have been deprecated in favour of class-based views.

#Codes are used to dodge translation in urls.
#Need to think of a better way to do this...

Probably all views in views.py should be protected by @login_required for security.

Some duplicate code in create_feedback() view:

return_page = unicode(decision.id)            
return HttpResponseRedirect(reverse('publicweb_item_detail', args=[return_page]))
...
    return_page = unicode(decision.id)
    return HttpResponseRedirect(reverse('publicweb_item_detail', args=[return_page]))

Similarly in process_post_and_redirect().

Why does sorting use a form? How about django-tables? Why does it need both a form and a 'sort' parameter in object_list_by_status()?

Decision.get_fields() is unused.

Decision.unresolvedfeedback() will be inefficient if there are too many feedback items. I think you could return a boolean (let the UI code handle how it's displayed) and use a one-line database query like:

self.feedback_set.filter(resolved=False).count()

Decision.feedbackcount doesn't need to be a model method at all, could be queried directly. .all().count() is redundant, just .count() should work.

#work in progress... remove email sending from model save: this can be done by listening to signals: https://docs.djangoproject.com/en/dev/topics/signals/

subject_template = Template(...) could use a file instead.

JQueryUIDateWidget looks useful, can we make this a separate component (perhaps an app) to be used in other projects?

"Last modified" column does not meet expectations

When I look at the last modified column, I expect that to mean "the last time anyone edited anything on this issue, or added feedback, or added a comment". The current times are certainly not that.

Make Choice of Columns configurable

Tom:

I think that we could probably do with having users define

what appears in their own list views, maybe via a column picker like
Redmine's.

Show the date on feedback items

Not prominently, but looking at an old issue, I have no idea how old the feedback on it is, except for having a vague memory of having seen it before in the dim and distant past.

Version number visible somewhere

It'd be nice to see what version of the codebase people were using to help diagnose and isolate bugs. Of course that means we have to have some standard. A placeholder would be good for now though!

Where to put it...

How about on the bottom of each page, next to "developed by Aptivate" ?

possible to mark feedback as "resolved"

at the moment this could just be a flag in the model. Controlling this flag needs thinking about once the current redesign of the proposal view has happened. Could be a checkbox on the feedback that e.g. shades it out

add "+1" or "I agree" functionality to feedback

Will need a way in the model to link multiple users to one piece of feedback
...then a way in the UI for people to agree with other people's feedback.

these two could be separate things.

Cancelling edit of Decision gives 405 error

Steps to reproduce:

Adding the following to django/openconsent/publicweb/templates/item_detail.html (at around line 80) fixed the issue for me.

        $('#decision_update_form input[value="Cancel"]').live("click", function (e) {
            e.stopPropagation();
            replaceWithRemote("{% url 'publicweb_decision_snippet_detail' object.id %}", 
                                "form#decision_update_form");
            e.preventDefault();
        });

Swap email text around so effect is easy to understand

Emails notifying changes currently arrive in the form:


This is to let you know that the following item:

"Strategy Proposal

blah blah blah blah blah

"

has been changed. [or "has had its status updated" or suchlike]

Although the subject of the email does let people know what's going on, it would be nicer if the email read:

This is to let you know that the following issue [note word change] has been changed:

"Strategy Proposal

blah blah blah

"

"Comment" button on a comment should scroll box into view

When there's already a lot of comments on a comment, I have to click on the Comment button and then scroll down to find the box.

Perhaps the "comment" button could be at the end of the existing feedback, to ensure it's been read and isn't being duplicated, but that's a separate issue? or both before and after the existing feedback?

Anyway it would save some clicks and mouse navigation if clicking "Comment" scrolled down to the edit box, like it does on a decision or proposal.

Duplicate Decision Description Bug

Creating two decisions with the same description creates a display error when the list page is viewed.

In this case the template filter is unable to identify a unique entry based on the excerpt and so returns none.

Duplicate list entries are therefore displayed as having id "None" and description "--"

Cross-browser testing

Have had issues in past between IE 6 and 7, think maybe fixed now.

Browsers to test:

IE6,7,8,9 ?

FF 3+? Ignore all recent "rapid releases" except latest?

Safari

Chrome

Opera?

Split title and body of discussion/proposal

Econsensus silently takes the first line of the discussion/proposal as the title. I usually forget to write the first line as a summary.

I suggest having a separate Title box above the Body of the new discussion/proposal.

Python 2.7 is not supported

Openconsent fails to install (./deploy/tasks.py deploy:dev) on a machine with Python 2.7.

This is due to the fact that the string "python2.6" is hardcoded in the Python scripts (e.g. #!/usr/bin/env python2.6)

Changing this to simply "python" fixes the problem (on my fork):

$ find ./ -name *.py -exec sed -i "s/python2.6/python/" '{}' \;

The files that are modified are:

  1. deploy/fablib.py
  2. deploy/tasklib.py
  3. deploy/tasks.py
  4. django/openconsent/manage.py
  5. wsgi/wsgi_handler.py

Best.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.