Check in with MoCo on their use of django

[Pomax]

We will want to check in with pmac and tasos to find out how django is being used on the MoCo side, specifically in terms of the following questions:

• What django bolt-ons are they using?
• Who are they giving django access to?
• How many people are usually “needed” to be on that to keep it running (i.e. what is the general FTE commitment necessary to keep things up and running)

[kristinashu]

It would also be helpful to have a list of Mozilla sites that get updated by program staff (and volunteers?) in a django interface. This will help determine who to interview in https://github.com/mozilla/network/issues/11 and which bolt-ons might be relevant to review in https://github.com/mozilla/network/issues/12

[kristinashu]

Meetings are set with pmac and jwhitlock for later this week.

http://etherpad.io/p/moco_django

[kristinashu]

Notes from meeting with pmac:

• he works on bedrock where the admin is very basic (Program staff just add newsletter link to site) so it isn't the best example
• bolt-ons:
  • we can add skins as an admin replacement
  • https://github.com/sehmaschine/django-grappelli
  • CRM packages
  • https://github.com/elky/django-flat-responsive might get merged into django core
• who has access
  • staff
  • close contributors (thunderbird team release note)
• security reviews are an issue
  • join the django security mailing list/bugzilla group to get sec.issues before they go public
• big jumps from version to version that break bolt-ons and grappelli
• others people to talk to:
  • Osmose (Michael Kelly)
  • someone from sumo (will ask roland at office who to ask)
  • someone from MDN (if django rather than wiki): jwhitlock and will ask Stephanie at office

[kristinashu]

Notes from meeting with jwhitlock:

• he works on kuma for MDN https://github.com/mozilla/kuma
• direct admin pages access for staff and longterm contributors (to be locked down soon though due to security)
• you log into a front end and then you get to work with the backend data
• different tiers of access for different people (view vs edit privaleges)
• provide step by step directions to Program staff for a small specif job
  • example: admin decide if a new edit to wiki is spam or not. They see list, can filter, see detail, then chose from a dropdown if spam or not.
• forms are tough
• django is (was?) the basis for dynamic sites, DRF is an option but you're going to be fighting the framework a bit
• familiarity with the traditional concept (post to site -> page refresh, rather than ajaxy in-page stuff)
• standard django with jinja2 templates
• uses some custom JS for UI updating (example filtering list)
• uses pantoon for mdn - in line edit and then save
• handy util for python deps: requires.io to examing requirements.txt for deployed codebases (can flag green/stale/insecure/etc) codecov.io for code coverage
• https://requires.io/github/mozilla/kuma/requirements/?branch=master
• recommends we talk to pantoon people: Poke Osmose and Mathjazz for how they use django in pontoon

[kristinashu]

Jezdev mentioned these for CMS: https://www.django-cms.org/en/ and https://wagtail.io/

Django CMS looks excellent from a Program Staff usability stand point. Would be great to see how viable it is from an engineering stand point.

[kristinashu]

Notes from meeting with Matjaz:

Pontoon

• currently one developer (matjaz), one volunteer (jotes) (~1.5 FTE)
• the admin side is really just two custom views, actually considering switching to stock Django admin
  • the maintenance required is high because it would need work to look sleak (writing widgets, etc)
• users:
  • purely volunteers (~700 active users - having contributed in the last 2 months)
  • hired agencies for legal translation
  • roles
  • logged in user (you can contribute suggestions)
  • translator (someone who can approve translations and submit own translations)
  • team manager (translator + able to give permissions to users)
  • admin (basically team members, able to add new projects, enable locales, full access to pontoon admin view as well as django admin view) (four people atm, 2 engineers, 2... might be...?)
• "things have to be really simple" so no specific technical skills should be necessary to use the system
• mostly stock Django
  • no third-party addons/skins/etc, view content is in-house
  • standard web techs like jquery, webfonts, etc.
  • originally used django oauth for logins
  • no auth0 (yet)
• new project => basic data input into form that defines "a project", this then sets up a view that can load that project
  • every 20 minutes there is sync from pontoon django to the code repository, which then sets up all the pages (dynamic django views) and dashboard.

[kristinashu]

@Pomax I think we can close this ticket, agree?

[Pomax]

yep, I think so.