================
Datatracker PLAN
================

Updated: $Date$

Planned work in rough order
===========================

* Transition to Django 2.2 (via 2.0 and 2.1).  This depends on Python 3.x.
  Security updates to Django 1.11 will cease around April 2020.

* Transition to PostgreSQL.  This will make it easier to start using
  timezone-aware timestamps throughout the code, which will make it easy
  to present localized times on web-pages.  It will also provide additional
  tools for performance analysis

* Investigate making RFCs first-class document objects to faciliate being
  able to model BCPs that represent groups of RFCs properly. Then fix the rfc sync
  script to update BCP aliases when changes occur changes (a BCP points to new
  RFC numbers)

* Polish the htmlization pages, making the style identical with tools.ietf.org.

* Investigate adding code to trigger test exceptions for template variables
  that don't successfully resolve.  A small trial run of this has indicated
  that most instances that trigger such exceptions would benefit from better
  resulution -- i.e., in the trial, it didn't seem that we to any greater
  extent have template code that is written to rely on failure to resolve
  rendering as nothing.

* Add django pagination to selected pages with long lists of results in order
  return results to the user faster.

* Change our web asset handling from the current bower-based (which has been
  deprecated and gradually more and more unworkable) to a yarn-based setup.
  Short-time the effect of not having the web asset updates in mkrelease is
  negigible, but long-term the lack of this means that we may miss
  security-updates to web assets.

* (EXTERNAL BID) Reworked UI and refactored backend for the scretariat meeting
  scheduling tool.

* Add support for internationalised email addresses according to RFC 6531
  when sending email (this is not supported by smtplib under Python 2.7,
  so will need python 3.x).

* Test suite improvements.  Reduce and seek to eliminate causes of differences
  in code coverage between runs in the same and in different environments.

* Rework email subjects for messages relating to documents to consistently
  start with the document name.

* Revisit RFC author ordering and author information based on rfc-index.xml

* Revisit photo uploads: Add photo upload for people with roles.  Add
  photos to wg pages and group overview pages.

* Revisit floorplans: Add room coordinate input tool (javascript).
  Add NOC object annotation possibilities.  Add support for break areas
  on multiple floors (probably means modelling break areas the same way
  as other sessions, and removing the break_area char_field on Meeting.

* Add the ability to volunteer for Nomcom when logged in to the datatracker.

* Transition to using timezone-aware timestamps.  Migrate database timestamps
  to be timezone-aware.  This means converting all timestamps to PST8PDT,
  except for meeting-related timestamps, which use the meeting.time_zone.
  Once done, set USE_TZ to True in settings.

* Add support for document shepherding reports, possibly re-using or
  generalising some of the review plumbing.  Check with IESG for details.

* Performance analysis of database table and index setup

* Refactor Document and types into Document subclasses, with conditional code
  in views and utilities moved into models and overridden models where
  handling differs between document types.

* When draft XML source is available, take references from that instead
  of extracting them from the text version.

* Integrate better author data for RFCs from either the RFC Editor or from
  running the author extraction script on newly published RFCs.

* Add an FK to person from author, and use that instead of the unknown-email-*
  addresses to connect documents to authors when no email address is available.
  (we still need to keep author email addresses in order to know which
  address to associate with a given authorship, when we have an address).

* Review places where we display persons' names but link to email addresses.
  Some of those probably should link to the person's profile page, instead.


Notes
===========================

* Small nomcom refactoring: associate Feedback records with Person
  instead of User.

* Consistency fix: in settings.py, name directory settings consistently with
  ..._DIR; reserving ..._PATH for settings with PATH semantics (':'-separated lists
  of directories)

* For documents with Yang modules, add links to the extracted modules (possibly in
  multiple formats -- pyang can generate a large number of alternative formats)

* When we get to the point where we can produce pdf from xml+media, remove the
  pdf upload possibility -- it's a definite attack vector.  Possibly start scanning
  pdf files for /JS and /JavaScript (and workarounds to hide Javascript)

* Add one or more API description pages with examples of common queries

* Add role lists and additional relevant information to the personal profile
  pages

* Increase the requirements on valid email addresses in draft submissions --
  contacting authors is hard if they don't provide an email address.

* Make it possible to let time run backwards in the database (creation timestamps,
  universal changelog)

* Change slugs which were limited by the former 8-character slug length limit
  to be more readable (needs both code changes and migrations).

* Additional charts, various statistics views.

* For graphing and mapping various numbers relative to country population, 
  integrate population data from the world bank,
  http://databank.worldbank.org/data/reports.aspx?source=2&series=SP.POP.TOTL&country=
  (or some other source, if a better is found).  WorldOmeters has running counters,
  but ask for a lot of money for even one.

* Notable New Django Features in 1.8:

  + New data types: UUIDField, DurationField
  + Query Expressions (enhanced expressivity, conditionals, database functions)
  + Improved TestCase fixture loading, additional .setUpTestData() method.
  - Support for alternative template engines
  - Security enhancements (request/response cycle middleware)
  - PostgreSQL-specific fields

* Notable New Django Features in 1.9:

  + New on_commit() hook, for post-commit actions, for instance sending email
  + Password validation option with pluggable validators
  + Running tests in parallel
  + DateTimeFields can be queried with date
  - Permission mixins for class-based views
  - New admin style


* WG document state slug renaming.

  adopt-wg	-> adopted-by-wg
  c-adopt	-> candidate-for-wg-adoption
  chair-w	-> waiting-for-chair-goahead
  dead		-> dead-wg-draft
  info		-> adopted-for-wg-info-only
  parked
  sub-pub	-> submitted-for-publication
  wg-cand	-> wg-candidate
  wg-doc	-> wg-document
  wg-lc		-> wg-last-call
  writeupw	-> waiting-for-shepherd-writeup

* Clean up and normalise the use of canceled / cancelled.  User-visible
  strings should already be all CANCELLED except when manually entered.

* DjangoCon Europe 2017 Notes:

  - Add tracing of Django Query methods from code through templates to the
    sql_queries list provided by 'django.template.context_processors.debug'
    (DONE)

  - Consider rewriting user switches using feature flags, for instance with
    gargoyle.

  - There is now a Django-REST-Framework add-on app which makes it easier to
    do something similar with DRF as with Tastypie.  As Tastypie is not being
    actively maintained, and DRF seems to have better performance, consider
    building /api/v2 using DRF and drf-schema-adapter / drf-auto-endpoint.

  - Consider adding JWT (RFC7519) support for /api/v1 /api/v2, to generate an
    access token from a login, and use that instead of session support for
    access control to access limited endpoints.

  - Once we're on Django 3.5, start using static type annotations to improve
    early discovery of incorrect function/method usage.  There are add-on
    files avaliable for Django which provide type annotation for Django
    functions and methods, and the Python stdlib is type annotated starting
    with Python 3.5.  Check static typing violations with 'mypy'.

  - Consider providing a user-selectable option to import photos from
    gravatar.

  - Consider using django-12factor to apply part of the 12-factor app
    philosophy: https://12factor.net/