This project has been moved to https://github.com/CiviWiki/OpenCiviWiki
civiwiki / openciviwiki Goto Github PK
View Code? Open in Web Editor NEWBuilding a Better Democracy for the Internet Age
Home Page: https://civi.wiki
License: Other
Building a Better Democracy for the Internet Age
Home Page: https://civi.wiki
License: Other
This project has been moved to https://github.com/CiviWiki/OpenCiviWiki
As part of our community building and outreach efforts, we can maintain a list of issues that are good for new contributors. We can also promote the new issues list via social media and developer communities.
Note: The idea here would be to make CiviWiki the "GitHub for democracy".
As a civi author
I would like to allow other members to suggest edits to my civis
so I can approve edits and collaborate with other community members
Create a workflow that would allow Issues to be edited by multiple persons. The workflow should have a primary 'editor', who is responsible for approving changes.
Bill
data modelIssue
Representative
Jurisdiction
Vote
https://bramp.github.io/js-sequence-diagrams/
Title: Third-party API integration
Client->Server: (1) call internal API
Server->API: (2) make authenticated request
API->Server: (3) Return data
Note right of Server: Save response to local db
Server->Client: (4) relay data
Note right of Client: Channel
Note right of Server: REST
Before a Bill is linked to a Civi, we shouldn't store any data on it. Users should be able to search all bill names/numbers available through Openstates/Pro-PublicaCongress, and then link any of those bills to a Civi. Once a bill is linked to a Civi, we then need to save its core info to our database and track it through the legislative process.
The Bill collection could have the following fields:
identifier
: String - unique identifier to identify the billname
: CharField - human-readable name of billjurisdiction
: ForeignKey - relationship to a jurisdiction recorddescription
: TextFieldprogress
: CharField - stages for bill progressopen_states_id
: CharField - unique identifier from Open States service, if bill is state-levelpro_publica_id
: CharField - unique identifier from Pro-Publica service, if bill is federalcivis
: ManyToManyField - multiple bills can be related to a civi, multiple civis can be related to a billA method could be defined to get all votes
for a particular bill, using one of Django's built-in backwards relationship helpers
Based on the initial Bills API design review, add the following enhacements:
bill_id
field for the ID of the bill in congress or at the state levelscope
parameter requiredstate
parameter
There are several branches in this GitHub repository that have been merged or might be stale. Consider deleting merged branches, since they are now part of the main-line, and getting rid of stale branches too.
Remove old branches for a cleaner development environment.
There are often properties defined in the CiviWiki models. The convention seems to be something like:
def _internal_property_function(self):
return
exposed_property = property(_internal_property_function)
There is an alternative, perhaps more elegant, syntax that uses property decorators:
@property
def exposed_property(self)
return
Consider using the alternative decorator syntax for CiviWiki model properties.
Although this project has been under development for some time, it is not too late to make an official, initial release. Once we have determined a project versioning scheme, make an official release on GitHub.
Git is trying to track changes to the staticfiles directory. Add staticfiles to .gitignore
, so Git will not track the default staticfiles directory.
As a software project, we should release periodic versions. To release sequential versions, we need to decide on a versioning scheme.
CiviWiki seems to depend on Python 2.7. What are some of the reasons for staying with 2.7?
Support the latest features of Python, such as async
/ await
, by updating CiviWiki source/dependencies to support Python 3.
The repository appears to be behind the old repository, because the default branch is 'master'. Set the default branch to 'dev', so we see the recent changes.
Django 1.11 is the latest Long Term Support (LTS) release. Test the project with Django 1.11 and upgrade if possible.
Upgrade project to latest Django LTS release.
While this project does not have a clearly defined coding standard, it is a good start to make sure we use meaningful variables to avoid mental mapping. This means that all variables should explain what they are, rather than using, for example, placeholders.
# bad
a = get_apple()
o = get_orange()
s = make_smoothie(a, o)
# good
apple =get_apple()
orange = get_orange()
smoothie = make_smoothie()
Clean code JavaScript has some good examples that equally apply to Pythin:
As part of our work to keep the code readable and maintainable, we can use the Flake8 tool to check for code style problems.
Run the Flake8 tool on the CiviWiki codebase. Identify problems and create a roadmap to resolve errors. Close this issue when our code passes Flake8 tests.
Flake8 reported several problems with our code, which have been noted in separate issues:
Close this issue once the above issues have been resolved.
When running a Flake8 scan (#33), several errors were reported related to undefined variables.
Make sure all needed variables are defined in project, to prevent bugs. Pass Flake8 scan, particularly as related to undefined variables.
Check the following variables to see if/how they should be defined, and resolve the related Flake8 errors:
There is a TODO in settings.py
to 'fix the CSRF middleware'. This issue is a placeholder to make sure we resolve the issue with CSRF middleware.
What is the issue that prevents us from using CSRF?
We may have migrated to this new repository without some of the most recent changes. Lets make sure we have all recent changes by pulling once more from the precious repository.
In order to set a good foundation for community building, we can adopt a code of conduct. We don't have to spend a lot of time inventing a code of conduct, and can simply adopt an existing one that we agree with.
While scanning the project with Flake8 (#33), we received several errors related to unused imports.
Resolve all Flake8 errors related to unused imports.
The following Flake8 errors should be resolved:
Our README is pretty much the first thing people see when visiting this repository. In preparation for the 0.1 release, we should have a well organized README.
Have a user-friendly, informative README.
Note: the README, like the project, is a work-in-progress. We just want to spruce it up a bit for the 0.1 release.
As part of our commitment to code quality, we can measure test coverage in our project.
Generate a test coverage report. Open an issue/discussion about improving test coverage.
In settings.py, there is a TODO saying to 'Add non-webapp template directory'. This issue is a placeholder to encourage that we complete the TODO.
There is currently a TODO in our api/urls.py
to build the API using Django REST Framework (DRF). This issue is to earmark that work, and track progress towards the goal of using DRF for CiviWiki REST APIs.
After running Flake8 (#33), we received several notices about spaces and indentation in CiviWiki sourcecode.
Use consistent indentation and spacing throughout CiviWiki sourcecode. Conform to guidelines of PEP-8.
Clean up the following Flake8 errors:
For some reason when adding a new project requirement, many lines are changed. This is despite the versions of other requirements remaining the same. As a result, any pull request with a change in requirements may be more difficult to review.
Have a well-organized (alphabetized) requirements.txt file. Make it obvious what requirements have changed when reviewing pull requests.
pip freeze > requirements.txt
to reorganize the requirements.txt fileCurrently, there is a delay when creating a new thread. The 'thread created' message appears, but the modal is still open.
Determine how to optimize the flow when users create new threads, so they receive immediate feedback on success. I.e. the modal might close at the same time the success message displays (while triggering redirect is in progress).
As a general guideline, we should strive to keep our project dependencies up-to-date. In order to help with this, there are online services that can check our project dependencies and indicate when dependencies are insecure or outdated.
Requires.io is one service that will monitor Python project dependencies. It also offers a badge that can be placed in our README as a reminder to update dependencies.
Pyup will monitor project Python dependencies, and send a pull request when security updates are needed.
Find an automated method/service to monitor CiviWiki project dependencies. Have a visual indicator in our README for community and contributors to see the dependency status at a glance.
If we decide to go with requires.io, then the following steps are relevant:
In order to keep a clean codebase, we should clean up any code that is not in use. This includes code that has been commented out, without a 'TODO' comment.
Keep a tidy codebase by removing commented-out code.
Clean up the following files/lines that have commented out code.
OpenCiviWiki/api/models/civi.py
Lines 99 to 100 in dbacc71
OpenCiviWiki/api/models/fact.py
Line 7 in dbacc71
OpenCiviWiki/api/models/rebuttal.py
Line 4 in dbacc71
OpenCiviWiki/api/models/rebuttal.py
Line 13 in dbacc71
OpenCiviWiki/api/models/representative.py
Line 10 in dbacc71
OpenCiviWiki/api/models/response.py
Line 4 in dbacc71
OpenCiviWiki/api/models/response.py
Line 14 in dbacc71
Lines 14 to 48 in dbacc71
Lines 76 to 79 in dbacc71
Line 140 in dbacc71
Lines 158 to 159 in dbacc71
Lines 162 to 165 in dbacc71
Lines 177 to 179 in dbacc71
Lines 188 to 212 in dbacc71
Lines 226 to 228 in dbacc71
Line 10 in dbacc71
Lines 46 to 102 in dbacc71
Lines 126 to 135 in dbacc71
Lines 145 to 146 in dbacc71
Lines 168 to 170 in dbacc71
Lines 555 to 581 in dbacc71
Lines 735 to 737 in dbacc71
OpenCiviWiki/frontend_views/views.py
Line 95 in dbacc71
OpenCiviWiki/frontend_views/views.py
Lines 100 to 106 in dbacc71
We should use explicit relative imports within a module. This promotes portability and readability.
Change CiviWiki modules to use relative imports where possible.
The following files/lines can be changed to use relative imports.
OpenCiviWiki/api/models/account.py
Lines 20 to 22 in dbacc71
OpenCiviWiki/api/models/activity.py
Lines 2 to 4 in dbacc71
OpenCiviWiki/api/models/civi.py
Lines 2 to 5 in dbacc71
OpenCiviWiki/api/models/civi.py
Line 12 in dbacc71
OpenCiviWiki/api/models/notification.py
Lines 2 to 4 in dbacc71
OpenCiviWiki/api/models/rationale.py
Lines 2 to 4 in dbacc71
OpenCiviWiki/api/models/rebuttal.py
Lines 2 to 3 in dbacc71
OpenCiviWiki/api/models/response.py
Lines 2 to 3 in dbacc71
OpenCiviWiki/api/models/thread.py
Lines 2 to 6 in dbacc71
OpenCiviWiki/api/models/vote.py
Lines 2 to 3 in dbacc71
Line 11 in dbacc71
Line 14 in dbacc71
Line 4 in dbacc71
In the Enable beta access for new user section, it is supposed to read "Once you have submitted the new user registration form, but for the word form". It has it as fom
Part of open project leadership is to have a clear idea of what we want to build, and to be able to quickly communicate that vision to stakeholders. The Open Canvas provides one such tool to quickly summarize a project. It lays out the parameters for building a Minimum Viable Project.
Be able to communicate the high-level goals of CiviWiki to potential community members and stakeholders.
/docs/organization/
)As part of our commitment to clean and maintainable code, we can lint our JavaScript. Linting will catch low-level details and encourage common coding conventions between CiviWiki developers.
Enable automated linting on the CiviWiki project.
There are several issues open in the previous repository. Migrate all open issues to this repository.
When I type in my address (not use the "Locate Me" feature), it loads the representatives. But when I leave the page (go back to my feed), and come back to the user account page, my address is gone and the list of representatives is gone.
After I tried to use the "Locate Me" feature, it again loads the representatives, but after I leave and come back the location info is missing along with the representatives.
As I was following the directions to set up a dev environment, I ran into an issue when trying to run pip install -r requirements.txt.
This is the error I copied from the shell...
Collecting psycopg2==2.6.1 (from -r requirements.txt (line 8))
Using cached psycopg2-2.6.1.tar.gz
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/psycopg2.egg-info
writing pip-egg-info/psycopg2.egg-info/PKG-INFO
writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
writing dependency_links to pip-egg-info/psycopg2.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
Error: You need to install postgresql-server-dev-X.Y for building a server-side extension or libpq-dev for building a client-side application.
After doing some searching, I found some instructions. Running the following commands
$ sudo apt-get install python-psycopg2
$ sudo apt-get install libpq-dev
Then I reran the pip install -r requirements, it ran successfully.
In order to retrieve data from Pro Publica and Open States APIs and send it to clients, we will need a 'wrapper' API. This way, we don't expose our CiviWiki API keys for the upstream services to CiviWiki users.
Produce a design for the CiviWiki API endpoints, using a standard format. Get feedback on the API design.
Code in a collaborative project should be consistent, and hopefully self-documenting. Consistency and clarity help new contributers, code reviewers, and existing developers understand the code.
Choose code standards and describe them in the contributing guide.
After running Flake8 (#33), we found that there are many unused imports in the CiviWiki codebase.
Remove all unused imports from CiviWiki code:
Following best-practices (recommended for example by Two Scoops of Django), we should move our Django project source code into a sub directory of this repository. Then, we can include other directories and files at the root level, such as documentation.
Reorganize CiviWiki repository to follow conventions established by Django community. Make room for other types of information to be stored in this repository, such as designs and documentation. E.g.
project
The sign-up process for new users is somewhat confusing.
The user is presented with an apology message immediately after filling out the sign-up form, which seems to indicate that the platform is in closed beta. However, an account activation email is still sent to the user, allowing them to complete the registration process.
Upon filling out the registration form, the user might see a welcome page. The welcome page can inform them to check their inbox for an activation email. The confirmation screen might also mention that the site is in open beta.
Alternatively, the site might disable registration until open beta.
Docstrings exist in some models, but are not consistent. Add docstrings to all model files, class, and function definitions.
The project should make consistent use of docstrings.
While auditing the project code quality (#33), I noticed that several Flake8 rules were being ignored:
Lines 1 to 2 in 3c28729
While it may be desirable to ignore some Flake8 rules, there are likely rules being ignored that would encourage good coding practices. For example, we are lacking a lot of docstrings in CiviWiki modules and classes.
Refine the Flake8 configuration. Ignore fewer Flake8 rules. Improve our code quality/practices.
Many files in this project have a 'mish-mash' import style, where imports seem to have been added through accretion.
Two Scoops of Django (1.11) recommends that projects adopt the following import ordering:
Use consistent import ordering throughout project.
Re-organize imports in the following files:
Note: the goal of this task is simply to update as many dependencies as possible. Difficult dependencies can be updated in follow-up tasks.
As part of our commitment to ongoing maintenance and security, we can periodically upgrade project dependencies.
As of today (2017-08-30), pip shows the following dependencies are outdated:
Package Version Latest Type
----------------------- ------- ------- -----
asgi-redis 1.0.0 1.4.2 wheel
asgiref 1.0.1 1.1.2 wheel
autobahn 17.6.2 17.8.1 wheel
billiard 3.5.0.2 3.5.0.3 sdist
boto 2.46.1 2.48.0 wheel
celery 4.0.2 4.1.0 wheel
channels 1.0.3 1.1.6 wheel
cryptography 1.9 2.0.3 wheel
daphne 1.1.0 1.3.0 wheel
dj-database-url 0.4.1 0.4.2 wheel
Django 1.8.7 1.11.4 wheel
django-cors-headers 1.1.0 2.1.0 wheel
django-notifications-hq 1.2 1.3 wheel
django-storages 1.5.2 1.6.5 wheel
djangorestframework 3.6.3 3.6.4 wheel
docutils 0.12 0.14 wheel
gunicorn 19.6.0 19.7.1 wheel
h2 2.6.1 3.0.1 wheel
hpack 2.3.0 3.0.0 wheel
idna 2.5 2.6 wheel
jmespath 0.9.0 0.9.3 wheel
kombu 4.0.2 4.1.0 wheel
Pillow 3.4.2 4.2.1 wheel
psycopg2 2.6.1 2.7.3.1 wheel
pyasn1 0.2.3 0.3.3 wheel
pyasn1-modules 0.0.9 0.1.1 wheel
pyflakes 1.5.0 1.6.0 wheel
pyOpenSSL 16.2.0 17.2.0 wheel
python-dateutil 2.4.2 2.6.1 wheel
redis 2.10.5 2.10.6 wheel
requests 2.8.1 2.18.4 wheel
service-identity 16.0.0 17.0.0 wheel
setuptools 27.2.0 36.3.0 wheel
Twisted 17.1.0 17.5.0 sdist
txaio 2.8.0 2.8.1 wheel
vine 1.1.3 1.1.4 wheel
whitenoise 3.2 3.3.0 wheel
Piprot gives a slightly different summary:
Django (1.8.7) is 615 days out of date. Latest is 1.11.4
django-cors-headers (1.1.0) is 741 days out of date. Latest is 2.1.0
djangorestframework (3.6.3) is 101 days out of date. Latest is 3.6.4
docutils (0.12) is 818 days out of date. Latest is 0.14
gunicorn (19.6.0) is 301 days out of date. Latest is 19.7.1
jmespath (0.9.0) is 603 days out of date. Latest is 0.9.3
psycopg2 (2.6.1) is 658 days out of date. Latest is 2.7.3.1
python-dateutil (2.4.2) is 831 days out of date. Latest is 2.6.1
requests (2.8.1) is 672 days out of date. Latest is 2.18.4
whitenoise (3.2) is 244 days out of date. Latest is 3.3.0
dj-database-url (0.4.1) is 273 days out of date. Latest is 0.4.2
Pillow (3.4.2) is 260 days out of date. Latest is 4.2.1
daphne (1.1.0) is 89 days out of date. Latest is 1.3.0
asgiref (1.0.1) is 58 days out of date. Latest is 1.1.2
channels (1.0.3) is 146 days out of date. Latest is 1.1.6
asgi-redis (1.0.0) is 227 days out of date. Latest is 1.4.2
django-notifications-hq (1.2) is 374 days out of date. Latest is 1.3
boto (2.46.1) is 135 days out of date. Latest is 2.48.0
django-storages (1.5.2) is 199 days out of date. Latest is 1.6.5
Twisted (17.1.0) is 119 days out of date. Latest is 17.5.0
h2 (2.6.1) is 17 days out of date. Latest is 3.0.1
pyOpenSSL (16.2.0) is 277 days out of date. Latest is 17.2.0
service-identity (16.0.0) is 460 days out of date. Latest is 17.0.0
idna (2.5) is 154 days out of date. Latest is 2.6
celery (4.0.2) is 220 days out of date. Latest is 4.1.0
Keep project dependencies up-to-date.
Update most, or all, of the following dependencies:
When a dependency is difficult or impossible to update, add a comment below describing the problem.
The developer instructions are separated in two sections of the README. Combine the Developer instructions into one section.
The Google Maps dependency may be unnecessary, and poses an additional encumbrance when setting up a development environment. For example, without a Google Maps API key, the new user registration wizard cannot be completed:
Remove all code related to Google maps:
https://github.com/CiviWiki/OpenCiviWiki/search?q=google
As part of our clean-code conventions, all imports should be at the top of their file.
Move all imports to top of their file. No import errors when running Flake8 (#33).
The following imports should be moved to the top of their file:
In order to promote maintainability and readability, we can use common measures of 'code complexity' as heuristics when developing/refactoring code.
CodeClimate will automatically scan CiviWiki sourcecode, and return a score based on common 'maintainability' metrics. These metrics include file/function length, number of function parameters, duplicate code, etc. CodeClimate is free for open source projects, and is used, for example, by the Django project.
Have CiviWiki code automatically audited for maintainability and quality.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.