Meeting Notes

Meeting Notes

We keep project meeting notes here in the wiki. Meetings are shown in reverse chronological order, that is, newest on top.

Note that we started using Etherpad for some meetings, with the predictable result that now meeting notes are scattered between two places -- well, really three: here, etherpad, and occasionally OTS's internal notes.org in SVN. At some point we might do something to consolidate these, or we might not.

So if you are looking here for notes for a particular meeting, and you don't see them, check SVN and etherpad (the latter is somewhat hard to search in, but sometimes SVN notes have a pointer to the pad link).

2021-09-16 Frank/Dan/Karl internal weekly meeting.

Notes are at https://pad.opentechstrategies.com/p/torque-weekly-2021-09-16

2021-09-02 Frank/Dan/Karl internal weekly meeting.

Notes are at https://pad.opentechstrategies.com/p/torque-weekly-2021-09-02

2021-08-26 Frank/Dan/Karl internal weekly meeting.

• Geocoding

  Python has an abstraction library for geocoding, standardizing all the APIs of the common geocoders into one API. This is great because it means that at any point we can swap out the current expedient proprietary geocoder for a FOSS-ish one; we're not locked in at all.

• Dan will make the style changes currently in LLIIA2020 universal.

  See this example of where it really matters: https://torque.leverforchange.org/GlobalView/index.php/Multiple_Competition_Applications

• Dan's working on maps, on all competitions.

  Done by Labor Day, or maybe ideally by Sep. 3rd. Karl will check in on/around Sep. 1 when he gets back, but understands it may not be finished at that point.

• Column unification work waits until after the maps.

2021-08-19 Frank/Dan/Karl internal weekly meeting.

• Column normalization project: filtered search depends on this.

• Dan's plate: maps (see below) visualizations work, column normalization.

• Frank to do column normalization brain dump into an issue ticket.

• Dan to start work immediately on the "map of proposals per competition" feature. Initial estimate 1-2 weeks; Dan may update that as he digs in.

• Dan and Karl to meet to discuss a WMF proposal. (We did, the next week. It turns out WMF grants are for individuals, not orgs, so Dan may apply as Dan to do some packaging on SimpleBook and TeamComments. Frank and Karl talked and, no surprise, a WMF grant isn't really Frank's bag so he's fine with Dan running with this.)

2021-07-15 Jeff/Regina/Jim/Frank/Karl fortnightly check-in.

See https://pad.opentechstrategies.com/p/LfC-OTS_Check-in_Meeting_(7-15-21)

2021-07-15 Frank/Dan/Isabel/Karl internal check-in.

• Styles lookin' good on LLIIA2020

  Other competitions to follow, once styles are ready.

• Printing

  Dan needs to remove TOC from single-page. And needs to add logo to front page in a more generic way, not current hardcoded way.

• Dan has filed an issue for the two edit buttons problme.

• Dan will be out for two weeks starting July 26.

• GV performance: caching should improve things

  There will be some long-term cache invalidation work needed, but we can get response times to be okay for August 4th.

  Search pagination is not hard, and testing shows it will work

  TOC caching is also straightforward; just means we'll have blobs of HTML in our DB.

  Estimate: mid next week for basics of above.

• Maps

  Isabel made future-work-location maps, and as a bonus made a spreadsheet of locations that failed to geolocate. Will fill out that spreadsheet and we'll deliver it to LFC. Will be done by Friday, 23 July.

• Faceted search in GV

  Frank and Jim will make initial spec on Monday.

2021-07-12 Dan/Karl internal check-in.

User login problem is almost certainly because of a new PickSome bug, in which once you start using PickSome suddenly you can't log in anymore. Dan is fixing this right now. PickSome is enabled on just 100Change2020, Climate2030, RacialEquity2020 (and the last one was the one where a user encountered the bug).

2021-07-08 Isabel/Dan/Karl internal check-in.

• Geo / Maps

  Isabel, Dan, Jim have settled on 10 initial maps. They are already under way. First drafts are done; they look great and can even zoom.

• Book Printing

  Typography is up on LLIIA2020. We still have a list of things to be delivered at the end of the month.

• Visual editing vs source editing ("edit" vs "edit source")

  Karl noticed the weirdness; Dan filed issue #134.

• Fixing the empty-bullet-points-when-printing problem.

  Dan's creating an issue and then fixing this in each competition's template.

• Global View speed

  Dan will be looking into PG queries.

2021-06-25 Dan/Frank/Karl internal check-in.

• Book printing

  TL;DR: Printing v1 is done! Now we're adding LFC-like styling.

  Dan just deployed the latest SimpleBook: it uses the new terminology, has titles and subtitles working, etc. Next up: style changes as per Jim. Dan is starting to make changes to the CSS for that. Note that the CSS is unified for all printing now.

  DECISION: MediaWiki's internal revision system is version control. Dan agrees with this proposition wholeheartedly, and in fact wonders why anyone ever uses any other kind of version control, such as this new "Git" thing he hears everyone talking about and which he intends to check out some time soon.

• API / Geo

  Isabel is now generating maps from Torque data.

  Dan got some good geo-related questions from Jeff et al. Will start with those, and put results into GV wiki. Will start moving toward dynamic displays instead of static results, but we expect that at least the next few things will still be static results of course.

• Column unification, data rearchitecting, and filtered/faceted search.

  Next step for Frank (after returning from vacation in mid-July): change Torque to stop using spreadsheets for ETL, and instead upload structured data (JSON). First win: geolocation data. Long-term ambition of a more general rearchitecture toward all structured data.

  Search filtering / faceted search very much depend on having structured data in Torque. We can make some progress just by doing the geolocation data, but in general the more different kinds of filtering LFC wants to do, the more important this overall data rearchitecting becomes.

• Speed and response time.

  A number of issues, many of which are listed in Feature Requests and Roadmap doc. We're going to need to talk to LFC about whether filtering is more important to tackle first, or speed issues; right now our guess is filtering, based on conversations with Jeff and Jim.

• Data regularization

  Will cause more pain as in-app filtering gets closer to being like API usage. Therefore, we have no immediate action item here -- reality is not going to let us forget about this one, and it will tell us what to do first.

2021-06-17 Dan/Frank/Karl internal check-in.

This preceded today's checkin meeting with LFC. See also the LFC Torque Feature Requests and Roadmap document.

• Visual Editor is working

• API / Geo

  • Isabel's main task is converting textual locations to lat/longs.

  • Some Git tutoring (yay).

  • Work happening in lfc-analysis repository.

  • Tentative deadline for delivering: end of next week.

• Global View

  • Deployed, including initial TOCs. Reviewed roadmap doc.

• Book Printing

  • It's working!
  • Stylation is next up.
  • Dan will removing the item from the left-hand pane.

• CSV downloads

  • Right click on any table that has the "bs-exportable" class set.
  • But you just have to know this; there's no visible control.
  • More-general CSV downloads not implemented yet.

• EIN report now on Jim's plate.

2021/06/09-10 Frank/Dan/Karl internal check-in (held over two days)

• Book Printing

  SimpleBook is live on all the competitions, and v1 (with the terminology and eliminate-Chapter-option fixes) will be pushed today.

• MediaWiki upgrade

  Only 100Change2017 and LLIIA2020 are upgraded so far. Doing the others is next up on Frank's list.

  All wikis (not Torques, just wikis) are on MySQL right now, except for 100Change2017 which is on PG (because set up by Karl not Frank).

  DECISION: We should not change the MySQL wikis to PG right now. We should wait until the inevitable day comes when MW switches over to PG as the default recommended DB for MW, because at that point they'll probably provide good switchover scripts too, and we can just use those.

  Note that while MySQL->MySQL upgrade of MW works fine, PG->PG upgrade of MW error gets DB error with weird user permissions issues, though the error seems to have no effect on the wiki.

  Frank will investigate why the new visual editor that ships with MediaWiki 1.35 doesn't seem to actually work.

• Next up Frank will do Global View TOCs (ref:d6289030)

• After that Frank will deploy the new docs wiki.

• API

  Frank waiting for Dan to review Torque PR #50.

• Book Printing / SimpleBook

  In the "article" vs "page" vs whatever term, Frank reminds us that the needs of general SimpleBook users are probably different from what we need in LFC Torque.

2021-06-02 Jeff/Regina/Vernon/Jim/Frank/Karl alt-weekly check-in.

• MediaWiki upgrade: Per Frank, this will happen on Saturday (June 5).

• Kellogg: Jeff expects 20-25 new users (Kellogg + Dalberg). All reviewers will have access to all competitions. There will be an 18-person selection committee. 'Search' will be important as well as lists that group similar competitions for easy comparison.

• ETL workflow, upcoming schedule: Jeff and Vernon to keep OTS apprised of any deadlines changes that may affect ETL schedule.

  • Equality Can’t Wait
    • June 7 (Monday): Donor Due Diligence and Technical Expert Reviews due to LfC
    • June 8 (Tuesday): Data uploaded by OTS
  • Racial Equity
    • June 8 (Tuesday): Competition closes 
    • June 10 (Thursday): Ranking
    • June 18 (Friday): Data delivery

• Printing: Jim will provide OTS with an LfC-branded sample book.

• Table (CSV) downloads: This effort will wait until after column regularization, however, Jim will get output specifications from Lauren Stadler when she returned from PTO (June 7).

• Global View table of contents [ref:d6289030]

  • Annual Budget: Easy but requires regularization across 9 'buckets'
  • Funder Source: Data currently too inconsistent for this to be useful
  • Geography: Will be bucketed by applicant location
  • Highly Ranked: Easy
  • Subject: Again, data currently too inconsistent for this to be useful
  • Judge Score? Will be bucketed by fives: 100-95, 95-90, 90-85, etc.

• Competition column comparison: Jim to identify initial columns (+/- 100) to be regularized.

• User accounts: Unneeded local accounts will be blocked after the MediaWiki upgrade occurs. GSD asked to remove apps from unused Okta accounts. Goal is to get to +/- 150 users (from 315) by the end of next week (June 11).

• Help docs: Karl and Jim to meet to identify best location for user-facing Help docs.

• Initial geographic views

2021-05-24 Frank/Dan/Karl weekly check-in.

• QA process after updates

  E.g., is there a way we could have caught the Kellogg/RE2020 issues ECW issues Jeff mentioned?

2021-05-20 Jeff/Jim/Dan/Frank/Karl regular meeting.

• Book Printing group tire-kicking

  These notes are based partly on Dan's notes:

  • SimpleBook Notes:

    • Adding chapters causes errors.
    • Change "X pages" to "X articles".
    • Title / Subtitle / paper size should be supported. Paper size should default to "US Letter".
    • Add "add this page to book" from search results (esp. in Global View!) See below about "TOC-like situations" for more on this.
    • Should articles be right justified or left justified?
    • Do we want to have the chapter title pages?
    • Cambria (Serif) + Calibre (Sans Serif). Jeff to send us the style guide (he did so right after the meeting).
    • Jeff got a server error at one point. We need to be able to reproduce.

  • Ideas:

    • Saving books / have a collection of books. (Maybe even: copy a book and then edit the copy.)
    • PDF Embeds in the book.
    • Footer on each page showing application title / org.
    • Selecting/selecting from TOC-like situations. Note that the UI here could probably apply to search results -- that is, maybe we can treat search results like a kind of TOC. (Tooltips are a bad way to add articles to books. Tooltips are also broken right now, as it happens, in that titles with colons break the hover-to-add interface, but since we don't want that interface anyway we shouldn't spend time fixing it.)
    • We generally want more ways to add items!
    • Dan will deploy it to all the other competitions now.
    • OTS will write a little description of what's going on / why it matters. (TODO: This is on Karl's plate; send to Jim and Jeff for review. Emphasize how this will pair nicely with Global View and with Page Templates.)
    • Announcing within LFC: next week (or later).

  • Gathering more feedback / pending UI decisions:

    • TODO: Karl to run samples by Vernon et al for full-justification vs left-justification question.

    • View templates: not really reflecting reality right now; need to rethink. LFC wants a "Proposal Summary" template, for obvious reasons (for one thing that'd be great for printing summary-only books!). Unrelatedly, on non-primary tabs (e.g., "Evaluations" or "LFC Analysis" tabs), the View Template menu in the left side panel will still say "Full" even though that's being overridden by a different template in the tdcrender tag. So for one thing, we should only be showing the View Template choice on pages where that choice is actually meaningful. But fixing that may come out in the wash as part of a larger choice-of-View-Template redesign.

      TODO: Dan will file a ticket on this. Frank suggests referencing issue #19 when doing so.

• Data Uploads new process.

  We all know how the world works. We are grown-ups. We eat what is put in front of us. What's the Latin phrase for "'Nuff said"?

• Kellogg evaluation panels are under way now

  Thus, maybe ~3 weeks till we get the evaluation data.

• Global View

  Jeff has some additional TOCs he'll want to develop for Global View; he'll let OTS know. We also discussed fleshing out GV content to make that wiki look a bit more like the per-competition wikis.

• Upgrade of MediaWiki

  We will beta-test this upgrade on wiki.opentechstrategies.com, then do it on production. Frank has done the hard parts of the upgrade already; we're just down to testing now.

  When we upgrade, we'll have CSV exports of in-page tables "for free", because that plugin is already there and enabled, it's just been waiting for the MediaWiki upgrade.

• API

  • Two things we will keep separate:

    • Improvements to the API itself. These are coming soon and are relatively easy.

    • The larger project of column unification. This will be one big chunk of work at the beginning, but then it will also be a low-level background task running all the time forever. It should be thought of separately from the API improvements, although of course it affects API usage in practice.

  • API authentication

    We won't use Okta for API authn, because 2FA is painful in batch jobs. Instead, you log in via Okta first, and then set your local password. Use the Okta password for web-browser access, and local password for API usage.

    DECISION: Despite the clunkiness, we agreed that this is how we will do it for now. We can add a nicer UI, with things that look like normal API authn tokens, later if we want to.

    TODO: In the meantime, Frank will switch API local authn account passwords to strings that look like API tokens, so at least we're getting the aesthetics right. :-)

• Jim reported on consolidation of user accounts.

  We had ~315 accounts. Within the next week or so we should be able to get down to ~150, by removing duplicates, local-only accounts (which will now be converted to Okta), etc.

2021-05-16 Frank/Dan/Karl weekly check-in. (Had check-in a day early this week.)

• Friday request

  • Totally doable.
  • Plan is to say, we would like it by 3:00 PM EST to have complete by 5:00 PM EST
  • If it comes in after, we can update but it will be later in the night.

• NOTE FOR LATER: We need to talk about finalists and the long term impact of the current process.

• Future Processes

  • We aren't giving up the dream, but we need to help LFC carry it into their relationships / planning in future.
  • Karl can't be the one in charge of determining how to handle emergencies!
  • Dan + Frank will collaborate on whether we can handle ad hoc requests.

• Books

  • CSS tweaks finished; pushing live today

• Global View

  • In good shape (we had to end quickly so not much more detail)

2021-05-12 Frank/Dan/Will/Karl weekly check-in.

• Printing

About one day of work left till demo! Dan will ping Karl when ready. Will opened a PR for outfile support, as promised.

• MediaWiki upgrade

Deployment to demo server coming soon.

• Updating the API

Making new URL routes, and addressing everything in https://github.com/opentechstrategies/torque-sites/issues/84 that we plan to address.

• Global View

Frank will solve the odd newline problems we found yesterday.

Column unification still needed. Karl to talk with Will about whether Will or Frank will do this.

Upgrading API leads to getting API users to use GV instead of using individual competition wikis.

Karl to propose geographic views to Jeff and come back with a list of a few views to do first.

• New process for updates

All looks good. Karl needs to put the docs in the right place and update pointers (e.g., from Google Docs).

2021-05-06 Vernon/Jeff/Jim/Dan/Frank/Karl regular meeting.

• ETL

  We discussed various improvements to workflow. Right after the meeting, we wrote up a proposal, which LFC is nowreviewing.

  Some recently-requested Climate2030 updates are not up yet. Dan looked into it after the meeting and fixed it.

• Printing

  Internal demo coming tomorrow. LFC demo in first half of next week.

  We need to choose which competition to deploy it to.

• Global View

  LFC continues to get requests like "all the climate proposals (across all competitions) in Texas".

  Would be great to start building out custom lists for GV. What if one could select in search results to generate a custom list, and then do something to that list: print it as a book, or make a new custom-list page, etc?

  Jeff named three things that will be key in GV:

  • API
  • Multi-competition orgs analysis
  • Printing

  Jim asked: what about presenting filters (SDG areas, etc)? I.e., Faceted search.

  A way to mark competitions as completed, so that completedness state is apparent in GV search results.

  The Kellogg Funders TOC is very exciting, Jeff said.

• Jim is getting user accounts simplified

  Has been looking at historical login data that Frank sent from the logs, is analyzing it, then will run the results by Jeff who will then (probably) say which accounts can now be disabled.

  Jim will then look at simplifying Okta groups / MW groups.

  Will will do first pass at column standardization, then Jim will pick it up from Will.

2021-04-27 2pm CT Vernon/Emma/Karl feature needs checkin.

Competitions vary quite a bit. Some donors use the wiki a lot, others don't (in one case, the donor doesn't really use computers -- although the support staff does -- and everything gets printed for the donor).

Vernon and Emma's period of greatest interaction with Torque is during process of choosing semi-finalists, making sure LFC has analyses ready to go: all the thoughts from LFC, from Bridgespan, and from outside advisors.

• Semifinalist proposal updates involves too much copying and pasting.

  Vernon: Once a competition has settled on the top 15-20 or so proposals, the team (LFC, Bridgespan, et al) write up a memo for each proposal, including a summary, the judges' scores, etc. They write it up in Microsoft Word (easiest to do it that way, though it's still a serialized process with Dropbox as the coordination point), and then once those docs are done they have to copy and paste into the wiki.

  All that copying and pasting is time-consuming -- not difficult, just time-consuming. If we could automate that ingestion, that would save a lot of time.

  Vernon says the move toward more uploading of PDFs, instead of editing wiki text, has been a lifesaver.

• Preparing the Top-N summary page is also time-consuming.

  Emma: another time-intensive thing is preparing the "Top 15" (or "Top N", whatever) summary page, with LFC recommendations, various summary columns, etc, for the donor to use.

  Her sources for this page are basically the same data that we upload to create each finalist page. She's just having to selectively copy-and-paste to create the summary page. (Well, we'd need to get the rank data, and the wildcard selections, which aren't currently in the semi-finalist proposal data that we get. But that information wouldn't be hard to obtain.)

  Vernon has been using an online table generator sometimes. Says there will be a table for every competition, so couldn't this be part of the wiki template? Emma agrees a table spitter-outer would be good.

• Fix the video link in PDFs generated from proposals.

  Emma: make the embedded video links be clickable in the generated PDF. Right now when you print a proposal to PDF (whether via single-proposal-page printing or via book printing), it doesn't hyperlink the video link. That is: it is printing the YouTube link, but it's just not a clickable link in the PDF. Right now she has to manually go through and fix it with a PDF editor.

• Quicker way to create Lists and Collections pages.

  Emma wants a quicker way to create Lists and Collections pages. She recently had to make like 15 different such pages, and had to do each one manually. She's planning to learn some editing macro tricks from Jeff, which may make this process a lot easier, so she recommends keeping this feature as a low priority for now. We should check in occasionally about it, though, since it wouldn't be all that hard to make some kind of form that takes a list of proposals (by title, review number, or both) and generates the appropriate Lists and Collections page from it.

• Usage or non-usage of voting/scoring features.

  These features have, somewhat surprisingly, not turned out to be all that often used in Torque. That's okay, but Karl wanted to better understand why, so we discussed it a bit.

  For the everything->semifinalist step, a lot of the process happens over Zoom. Voting and scoring are pretty ad hoc. It's not a very formal process, so there's no clear way to for Torque to support it. (Vernon says check with Muhsin and Jenna about this, though; he thinks they might have some more insights.)

  And in the semifinalist->finalist step, a lot of the decisions take place behind closed doors among the donor's staff.

• Sidebar Comments feature needs better privacy boundaries.

  Cecilia does add comments to proposals, but with the expectation that those comments will be seen by the Board (and possibly by the donor and the donor's staff?).

  But for staff, comments would need clear access boundaries: in practice, people are only going to put their thoughts into comments if they have some control and predictability around who's going to see those comments.

2021-04-21 Frank/Dan/Karl checkin.

• Dan has 2 main buckets right now:

  • Book Printing

    Has a fairly big PR that redoes how PDF logic is organized. That just gets handed a list of URLs, logs in, and generates a PDF with a TOC etc. Things remaining:

    • Implementing the needed authentication on the MediaWiki side.

    • The PDFs are still ugly, apparently due to CSS issues. (Frank points out that the only reason any fixed-width is there is so that things would look good when people hit Ctrl-p; said Dan should do whatever he needs to do.)

    • Some hidden tech debt in shortcuts taken to get a working demo (e.g., hardcoded title coming from the MediaWiki side).

    • FOSS stretch goal: publish this in the MediaWiki plugin system. (And what about Wikipedia then using it?)

    Estimated mid next-week for stuff visible to LFC.

  • Competition-level ad hoc debt

    Fixing some DRY violations while cleaning up some old commits for other reasons.

    LoneStar and Climate2030 had some attachments added, and LFC wants them in a tab instead of on the proposal page.

• Frank has the following:

  • Global View / PostgreSQL

    5 competitions are on PostgreSQL in production: EO2020, LLIIA2020, 2017, 2020, RacialEquity2030.

    Meanwhile, these are not on PostgreSQL: Climate2030, LoneStar, ECW, DemoView. (We laughed when we saw that last one; frank will pull DemoView over to PostgreSQL.)

    He'll deploy Global View today, and then the five on PostgreSQL will be on Global View!

    URLs to same proposal will be different between original competition and GV, for authz reasons.

    Re the Funders TOC in RacialEquity2030: This is the first time the ETL process asks a running wiki for something -- namely, an edits list to incorporate into the ETL pipeline. So now a dev env wiki could differ from prod wiki, despite using same code.

    Karl to file issue about Funders TOC and edits and regeneration. (See conversation about it.)

  • MediaWiki update and CSV exports

  • API improvements

2021-04-20 11:30am PT Jeff/Jim/Karl big-picture checkin.

• Check in on Kellogg

• Problem of funder org duplicates in "Other funders TOC"

• Dan doing LoneStar, Climate2030 updates today

• TODO: Karl to send note to Vernon (internal ref ref:72c0fbdc)

• Went over our six big areas:

  • Simplifying User Management and Improving User Support
  • Improving ETL Pipelines
  • Improving Publishing Capabilities
  • Improving User Experience, and Training and Decision Support Materials
  • Automating Aspects of the Public Website Updating
  • Defining a Common API for Grant Proposal Data

• See also internal ref ref:72c0fbdc for some more notes.

2021-04-02 3:30pm CT Dan/Karl Book Printing Check-In.

TL;DR: dev env is basically done. Now it's a matter of productionizing and solving the authn/authz issue (to make sure a person can't use the book-printing mechanism to get around access restrictions).

2021-03-29 Jeff/Karl check-in.

(OTS internal ref: ref:3b325652.)

• Migration to PostgreSQL: EOC yes; 100Change2017; 100Change2020; LLIIA2020

• Pending Stage 2 pipeline stuff

  In Dropbox, for LoneStar and Climate2030 Challenge, 5 docs each

  (Dan took care of these afterwards.)

• Incoming Kellogg competition

  Will get invalid proposals list later; we don't have it yet.

  We'll do it on current Torque, not on PostgreSQL/GV yet.

• Overview of Jim's remit.

  • Fixing the publishing chain: publishing custom collections
  • ETL issues
  • Users roles / perms
  • Documentation / training
  • Managing API use for Torque
  • Donor technical handholding
  • Partner Technical Collaboration Management
  • LFC user reqs management

• Discussed some bugs

  • When printing using current book printer, get rid of the Edit box next to each section title, and links aren't transmitted into the PDF reliably.
  • Status of custom export functionality that Dan worked on Karl talked to Dan and Frank about this afterwards.
  • Karl later (2021-04-20) emailed Muhsin re a conversation about what Torque isn't doing for him. CC Jeff, and bring in Dan.

2021-02-25 11am CT

Vernon Smith, Regina Shoykhet, Jeff Ubois, Dan Schultz, Karl Fogel

• Stage Two of EOC and 100Change2020 as a model for other Stage Twos.

  "The format that came out of 100Change2020 is, at a high-level, the format we're going use for future competitions."

• Give clear guidance to those developing Stage Two materials.

• Vernon says we actually do have control over the formats we receive.

  We do get Microsoft Word files -- it doesn't always have to be PDF that gets handed to OTS. Having a preset form/format into which social impact staff can input information manually is possible.

• Dan: need to decide on fields. It affects searching, GV, etc.

  E.g., Some competitions may not have accessibility review, and that's okay if so. But when a competition does have accessibility review, then let's make sure that we have standard field names for the reviewer and each of the fields in the review.

  This would make Global View much more useful, among other things.

• LLIIA2020, Climate2030, and LoneStar are coming.

  LLIIA2020 is probably most urgent/active right now.

• When will diligence documents for LLIIA2020 be available?

  Vernon says the DEIA reports might already be in. They're working on the rest, should be done this week.

• Vernon is okay with LFC copying data over into wiki format.

• Regina: Not all process feedback is in yet -- e.g., from Board.

• Are there any new types of diligence coming that weren't in 100Change2020?

  If anything fewer, actually. All that stuff that was internal to MacFound for 100Change2020 won't be there for other competitions.

• Prospectus PDF, appendices PDFs, budget

• RGML format as a standard?

  See RGML: a markup language for characterizing requirements generation processes. Not clear how widely used it is these days, though.

  (Note: we're not talking about "R Graphics Markup Language", which apparently also exists.

• Sidebar chat transcript.

  • What worked didn’t, known unknowns, what decisions need to be made
  • make decisions based on what’s the best UI - without needing to see it
  • Tab titles, orders, PDF vs Text
  • help us collect the data
  • Shorten implementation checks
  • cycles
  • Less stressed out
  • product will be better
  • EoC & 100Change as models for stage 2
  • Training video option
  • Simplify the ingestion format / give directions to LFC about that
  • No manual media wiki tables
  • define input format
  • Some are given by third parties as PDF
  • may not control that
  • Is their capacity to have LFC staff
  • or do we automate it (lots of work, not always possible)
  • What is the sweet spot format, eg ArchieML
  • Journos use it …
  • Word vs ArchiveML (vs Markdown???)
  • Don’t use bold for headers, use Header 1,2,3
  • If data transformation format vs meant for human consumption
  • We have control in what we receive from the DD pieces, can tell them whatever format we want
  • we do get word files (not only pdf)
  • Preset form for SI staff to input would be great
  • getting docs since November
  • Copy paste is acceptable if into structured pages
  • Decide standard field (accessibility review, entire document) vs (highlight headline, content)
  • Doc content, and reviewer as separate fields
  • Document, Reviewer, one to three levels more?
  • We have only two more Stage II wikis coming in the next quarter. Climate/Lonestar/LL
  • How to edit / create sections / batch import documents
  • Word for ingestion, headings use header 1,2,3; some content shits: how do we handle edits
  • We do edits via the wiki page , not via new upload
  • Map diligence fields by end of the week
  • calendar invite: biweekly 11 CT

2021-01-19 1pm CT Torque High-Level Direction Check-In.

Regina, Jeff, Dan, Frank, Karl

The key things right now are:

• Global View

  This is going to be big, and may cause people to realize more things they could do with Torque. So let's get it deployed already!

  It's mostly ready; we need to deploy the PostgreSQL changes plus some competition configuration tweaks.

  It ties in with API: the API needs to work with Global View.

• API

  API is important to many: Diana Reed, Candid, Center for High-Impact Philanthropy, Knowledge Futures Group (turns out Dan has some KFG connection, btw) and others will be using data from Torque and exchanging data with Torque.

  Some applications:

  • Ensuring that the selection process doesn't introduce bias. Identifying hidden bias is a priority for LFC. (CHIP at the University of Pennsylvania is doing some work on this?)

  • Geographic visualization / map integration, and other things related to data visualization, should all be experimented with via the API first.

• Book printing (i.e., book PDF generation)

  We're on it. Close to done already.

• User management, login, and access control issues.

  • Giving users a smoother first-time experience.

    Mapping Okta groups to MediaWiki groups is error-prone. Policy considerations mean the pain will continue, but let's do UX auditing (e.g., have LFC test new logins by creating a test account in the appropriate group along with the real account, in each request) so that the donors and their staffs have a smoother first-time-login experience.

  • Email address privacy.

    Some donors understandably do not want their email addresses visible. To be ultra-safe, we should keep those addresses out of Torque entirely -- if we don't have it, then we can't expose it. Since email addresses do not have to be visible to Torque, this is possible.

    TODO: Karl to formulate request to MacFound IT. Key phrase: "The email address should never go over the wire."

  • The "specialty groups" problem.

    The groups will continue to evolve. It'll never be perfect, because some new competitions and new donors will always have idiosyncratic needs, but it will asymptotically approach perfection the more competitions there are.

• New look-and-feel ("new style")

  Still on the agenda, but not as high-priority as the stuff above.

• Deprioritize "self-service" improvements for now.

  Deprioritize this for now. Incoming competitions will slow down for a bit anyway, and this is less important than the above items.

• Other things:

  • Some issues with incoming ECW financial analysis spreadsheets.

    Jeff has started a thread with Mary Gamber at Bridgespan (who is in charge of financial analysis) to resolve the format-inconsistency issues that Frank ran into.

  • Salesforce implementation: integrate w/ Torque?

    Schedule a separate team(s) meeting about integration between Salesforce CRM system and Torque. (From the Torque side, this could be relevant to our organization-duplication problem.) Regina has started the scheduling thread: "Re: Schedule availability (Wiki-Salesforce)"

  • Regina will be out on parental leave soon.

  • Need to fix printing bug torque-sites ticket #88, whereby printing an "LFC Analysis" page results in the letterhead being followed by an entire blank page before the TOC.

2021-01-19 11:40am CT Frank/Karl sync-up.

We checked in about requests recently handled:

• Making ECW2020 proposals editable.

• Adding LFC Analysis pages for all ECW2020 semifinalists.

• Various user account setup stuff.

• Various small permissions changes.

• 100Change2020: lots of PDF service

• ECW2020 financial data spreadsheet had wrong format.

  And for many of the 25 semifinalist proposals, the format is a little bit different from other proposals. The more complex the spreadsheet, the more complex the task of making the wiki page look good, because ETL ideally doesn't know about wiki format or HTML format, and therefore we have to keep making the Torque templates more sophisticated (remember also need it to work for API, so we can't lose field-type information).

2021-01-04 3pm ET Dan/Karl project initalization meeting.

Dan will first set up a local development Torque instance using the instructions and sample data there, to familiarize himself with the system.

Printing gets top priority. Our goal is to get the new book-printing feature deployed as soon as possible.

After that, Dan will learn how to use the ETL scripts in Torque-Sites (in combination with opass) and do things like handle competition data redeployments, user account creation and management, setup of analysis pages (e.g., "LFC Analysis" etc.

Karl gave Dan an overview of Lever for Change's priorities, and shared the LFC Torque Feature Requests and Roadmap document with him.

Addendum:

Dan, we didn't discuss this during the meeting, but note that Torque has an API and our production site has some API users (e.g., partner organizations working with LFC to do research about philanthropy). For an example of how the API can be used, see the find-multi-competition-orgs script (documentation is in that directory). For some real-life feedback from a third-party user of the API, see issue #84 in torque-sites. Handling some of that feedback is likely to be up next or very soon at any rate.

2021-01-04 8am CT Frank/Karl check-in.

Discussed upcoming onboarding of Dan Schultz, handover of printing work to Dan, and how Dan will ride along with Frank on some of the LFC requests so that Dan learns about ETL, account administration, setup of "LFC Analysis" pages and other meta pages, etc.

Karl will also do a roadmap review.

2020-12-30 4pm UK Mike/Karl review of printing feature.

See issue #1 for reference.

• Renderer autorefresh page should show estimated total time.

  Our super-rigorous scientific estimate is 2.5 seconds per proposal. Display a message on the page saying that the rendering might take that amount of time (as minutes:seconds), until the PDF is ready.

• Get rid of the "Proposal #N" under each proposal title in the PDF.

  This is on the actual first page (title page) of each proposal in the PDF, right under the title. It's easy to eliminate, so let's do so.

  (Now, if there's some way to get the actual proposal ID number routed through to be used as the number, let's do that instead. That would be great. But it's probably not trivial to do, and if it's not, then let's just remove the "Proposal #N" line entirely.)

• Put page numbers in the center bottom of the page.

  Instead of Karl's silly solution of putting them on the left and right sides, just put the page number in the center bottom of each page.

• Change the default from A4 to US Letter.

  This is important, since LFC and most of their partners use letter-sized paper.

• Change "pages" to "items" on the tops of proposal pages.

  Where it says how large the in-progress book is, talk in terms of "items" (by which we mean proposals) not "pages" (because while that actually means "wiki pages", people will interpret it as "PDF pages", which is not what it means).

• Change the wording on the continue-a-book-in-progress popup.

  Right now, if someone leaves a book-in-progress and then logs back in to the wiki and starts book creation again, they'll get a confusing popup:

  Click "OK" to continue with your book which contains 6 wiki
  {{PLURAL:6|page|pages}}.  Click "Cancel" to delete it and start
  with an empty book.
  

  Yikes :-). Let's change the wording to this:

  You already have a book currently in progress.  Click "Cancel"
  to delete that book and start a fresh one, or click "OK" to
  continue creating that book.
  

  (See this conversation in Zulip for more context.)

2020-12-23 4pm UK Mike/Karl printing check-in.

(Note: most of the items below are now captured in issue #1.)

• During book creation, header at top of proposal page says:

  "* Remove this page from your book * Show book (5 pages) * Suggest pages"

  Obviously they mean Wikipedia pages, but in the middle one that's confusing in an obvious way. Let's just change it to "item" (that header language is in locale files, so parameterization would be complicated -- not worth it, IMHO.)

• "Rendering finished" page has unnecessary Notes bit.

• Rendering didn't actually work with the five proposals we tried this time: 78, 3711, 211, 3341, 2410. Got a traceback.

  This was the comma bug.

• The progress meter doesn't work, even if you manually refresh the rendering page. (We need auto-refresh anyway, of course.)

• TOC is monospace font right now. But there's still an o.b.o.e. in page-number alignment (see first two items, on pages 2 and 10).

• "Key Partners" section of Makanah Project (3348) shows three extra bullet points in the rendered PDF. And those are actually present in the in original page, they're just invisible in the browser!

    <td>
    <ul><li>(Partner name omitted for confidentiality.)</li>
    <li>(Partner name omitted for confidentiality.)</li>
    <li class="mw-empty-elt"></li>
    <li class="mw-empty-elt"></li>
    <li class="mw-empty-elt"></li></ul>
    </td>
  

• All the little cleanup items from the "2020-12-15 9:30am AT" meeting are also still pending, of course.

The proposals we eventually printed were (in this order in the rendered PDF): 211, 3341, 2410, 3448, 3444, 3348

Everything is in SimpleBook repository, on branch feat/print-pdf.

Karl will file issue #1 with a list of all the glitches and buglets encountered in our two check-in meetings (the 15th, and today), so that we have a convenient punch-list to work with.

Mike and Karl will meet again in a week, on December 30th.

2020-12-21 4pm AT Frank/Karl check-in.

Unusual number of (and size of) one-off special competition requests. The request for 100Change2020, to make arbitary tabs that work specially with PDFs was non-trivial, and included a lot of iteration.

Frank made many of the changes in a re-usable way (i.e., in code, not in quick scripts) because we expect other competitions to reach a similar set of needs when they're down to a small number of finalists.

New data for ECW2020 and Climate2030 has recently come in, and Frank will be working on that next. Note that in both cases the incoming data "conflicts with" (i.e., supersedes) some edits that were made using the in-UI edit interface. That should be fine, but Frank notes that this is the first time we've done such supersession, so let's see if there are any glitches.

2020-12-17 1pm AT Jeff/Regina/Frank Regular check-in meeting.

(Karl was unable to attend today.)

Most of the conversation was about 100Change2020 requests.

Jeff also asked about Global View, and Frank basically said "talk to Karl". But what Karl would have said, were he at the meeting, is "Well, we decided to prioritize printing ahead of Global View; we could change that, but my guess is we don't want to."

2020-12-15 9:30am AT Jeff/Regina/Frank/Karl General discussion of current stuff.

• PDF iFrames in 100Change -> printing.

  There's a tab for appendices, holding 7-10 PDFs (it varies by proposal). This was not part of our printing plans, and it doesn't work well with printing right now.

  Short-term solution: ad-hockery and hand assembly.

  Long term solution: extend Book Collection UI to be able to add external PDFs (even ones taken from the Internet, not just from within Torque).

• API access.

  Karl is setting up Thomas and Diane with API access. (He finished this later the same day, after the meeting.)

• Budget tables for Climate2030

  This is on Frank's plate.

• PDFs for 100Change2020.

  This is on Frank's plate.

• Accounts - Okta setup

  Discussion of account management in general, and recent headaches Muhsin had. No definite new decisions (at least not that Karl, who was taking these notes, remembers), but we want to help Muhsin and Jenna have a better experience when they work with donors.

• Climate2030 update.

  This was listed on Jeff's agenda, but Karl doesn't remember now what it was specifically about. If anyone knows, please let Karl know and he'll update these notes.

• ECW ranking info coming tomorrow, judges next week.

  Sounds good; OTS is ready to receive.

2020-12-15 9:30am Mike/Karl printing check-in.

Basic printing is now working, with the new headless-browser-based rendering under the hood. Still lots of little things to fix, and no TOCs nor page numbers as yet.

It uses the same collection-like UI as we've always had for book creation. When you click the print-to-PDF button (or whatever it is), our API scrapes the necessary pages, with authn, and compiles them into a single PDF.

Some other things we noticed while running through a test session:

• Get rid of the two notices (one with exclamation point in red icon, the other with i-in-blue-circle) in Book Creator. They appear both on initialization (when you say you want to start compiling a book) and on the Manage Book page.

• Get rid of the suggested pages magic wand (which appears on each proposal once you've activated book creation).

• On the Manage Book page:

  • Get rid of the PediaPress link
  • Titles and Subtitles need to work, of course.
  • Default to Letter size, not A4.
  • Get rid of the Columns choice
  • Make autorefresh-while-rendering work.

• On the Rendering Finished page:

  Simplify, remove irrelevant stuff. Make download simpler: just pop up a download.

• In the rendered output itself:

  • Need proposal titles to be present.
  • Make the inline Contents go away.

• What's left to do to make Global View ready for production?

  • Prove out PostgreSQL back-end: it needs more testing.
  • Migrate all current competitions to Postgres.
  • Get them enabled in Global View.
  • API needs to work for Global View; that hasn't been started yet.

  This is definitely more than a day.

2020-12-09 9am CT Mike/Frank/Karl printing check-in.

Mike says we're getting pretty close

We have a command-line tool and a shell script. Together, they get the necessary login cookies, download the web pages into a PDF, and bind them together. Chrome -> PDF, and the formatting is controlled by how we display the web pages (i.e., by the CSS). It generates a PDF for each proposal and then concatenates those together.

However, that PDF is still missing a TOC, and missing page numbers.

What Mike's working on now: writing the API that will drive all of this, the one that we'll call from our SimpleBook plugin. After that comes TOC and page numbers. To generate the TOC, we just need to determine how many pages are in a given sub-file, which is easy.

2020-11-30 2pm CT Frank/Karl sync-up.

Installing the latest ExportTables would require upgrading to MediaWiki 1.35, which we want to do but which is highly non-trivial -- a bunch of things, including Javascript and book-printing, break. We have to look into why. So for now Frank is going to try an earlier version of ExportTables and see if that will do the job temporarily.

Frank will make sure that Global View is up-to-date.

2020-11-24 10:30am CT Frank/Karl sync-up.

• Frank is enabling the edit interface for Climate2030.

  Bad formatting in some of the Climate2030 raw data. This is what the edit interface is for. So Frank is enabling the edit interface in the Climate2030 template right now.

• Putting LFC Analysis tabs on Climate2030.

  This involves updating the ETL pipeline -- one-liner that just says "generate these pages for GIVEN_LIST of proposals", but GIVEN_LIST comes from the confidential list (i.e., from Subversion). Then the LFC Analysis page template needs to be written. It is usually similar to, but not exactly the same as, the LFC Analysis page from some other competition.

  So adding these tabs to the finalists is not a trivial thing.

• Global View: new and interesting questions keep coming up.

  In Lone Star, they care only about Texas; in 100&Change they care about the whole world. How do we make a Geographic TOC that works for both of those?

  We're probably going to have to make the renderer aware of who is rendering it, so that it displays things correctly for native competition versus GV. For example, when rendering a proposal (which GV does by simply calling out to the native competition's template), in that proposal the "Location" field's value is usually a link (to that location's corresponding section a geographic TOC specific to that competition). So when rendering it in GV, that shows up as a red link because that TOC page naturally doesn't exist -- in fact it was Regina who noticed this.

  Or another example: Many proposals now have an evaluations tab (or even multiple such tabs). The proposal's own Evaluations section even now links over to those tabs directly. But right now that's meaningless in GV, and thus either should not be rendered or else the rendering would need to be handled in some new way that will require a lot of thought to be given to it.

  Unexpected things like the above will keep coming up in GV.

• Self-service uploads.

  When uploading, link vs inline-embedding will be pre-decided in the template -- it's not something the user chooses at upload time.

  Every attachment is associated with a column in the spreadsheet. A given column can hold multiple attachments. Each attachment knows which column it is associated with, but a column does not know which attachments it is associated with. Sometimes a given column's data is the attachment filename, and the template knows how to use that filename to create the link to the attachment.

  We use all this in some interesting ways. For example, we create a column named "Can view financial attachments". Its value is ignored, but if a given user has access to that column, then that user can view financial attachments!

  So we'll handle self-service upload icons the same way we handle edit buttons: we just put the icon in the desired fields in the template, where we want it.

  Namespace management will be needed. If a bunch of different attachments all named "review.pdf" get uploaded, obviously they need to have unique names within this competition. So some combination of proposal review number, and maybe even field within proposal? Anyway, Frank says this is is solved by PostgreSQL, and we have multiple ETL pipelines that segregate attachments by proposal already -- so basically, this is already solved, we just to solve it the same way again.

  Self-service uploads are not urgent for 2020 in practice: we can handle the finalist documents they receive for the current six competitions manually. But it will be important in the long run.

  Karl wants to get them done in Q1 2021, because the anti-pattern we will keep seeing is that competitions go through intense times when they suddenly have a bunch of attachments to upload (e.g., for finalists, for updated versions of previous attachments, etc), and during that time we suddenly all wish we had self-service uploads implemented. Then the intense period is over, and the need stops feeling urgent. But it will come back! We should anticipate this.

• Printing

  Mike is working on it right now. See detailed design discussion from previous (2020-11-23) meeting.

• PostgreSQL rollout.

  Currently the PostgreSQL back-end is only in effect for draft GV. PostgreSQL is not used on the live competitions in any way yet. However, we'd like to migrate from the current flat-file world to PostgreSQL. That's a biggish task.

  For example, search in alpha GV is not fast, and that's with just two small-ish competitions. So what does this imply for a single large competition under PostgreSQL? Right now it's slow (we tested it); obviously that can be fixed, but we have investigate and fix it.

  Also, we have to make sure redeployment is properly idempotent under PG. And we have to write an ETL route for current edit data to get into PG universe. And, for example, today we found out that attachments don't work.

  So, there's a bunch of work and testing to be done before PG launches fully. That testing will be done by OTS. We don't want LFC to spend their time testing something that has regressions. They've been great about testing new functionality, but regressions are a different story and they shouldn't be exposed to those.

2020-11-23 11:30am CT Frank/Karl meeting about book printing, etc.

• Random stuff + tech debt cleanup is costing time.

  Data cleanups cost us development time. Also, Frank went through all competitions to make sure all "LFC Evaluators" can't see ranks, for example. Then Thursday was the meetings with Keith et al.

• Book printing.

  Book printing is broken right now because of customized layout things, such as:

  • Snapshot box
  • "LFC Analysis" pages
  • Budget tables

  How we'll fix it:

  Continue to use Collection (or some derivative thereof) to collect the relevant pages, and then use a headless browser (likely headless Chromium) instead of mwlib firing off to PediaPress's renderer to do per-page-printing. Then assemble those pages into a multi-page book-ish document. (See also Mike's description of the solution in Zulip.)

  This will in theory make book printing look like what's on the wiki, with some CSS adjustments conditionalized for printing. In practice, right now the web pages don't look good for printing -- MediaWiki's Vector skin makes it hard to fix that. Making our own new skin would solve that, of course; there are other possible intermediate solutions too.

  We'll generate one PDF file per proposal, then concatenate the PDFs, creating a TOC page (from an out-of-band list of proposal titles and other proposal metadata, which we'll easily have of course) and calculating all the page numbers programmatically and inserting them via standard PDF manipulation tools. This will allow us to handle page numbering and have a real TOC on every book.

  New repository will be named SimpleBook (Frank has created it) and will start as a clone (regular clone, not a GitHub fork) of upstream Collection.

2020-11-20 10am CT Meeting about Printing/Uploads

Frank, Mike, Jeff

• Printing

  Jeff signed on to say that there are three main needs for printing:

  • When a word document comes in, and it's translated to the wiki, there are often edits to the wiki. Then someone wants it printed back out, and the best printout of the page is the word document, but the best information is on the wiki.

  • There's a donor that wants a large printout of a number of proposals. For instance, the finalists for a competition

  • The "Water in India" problem. Someone wants to figure out which proposals in all of the competitions are related to some topic. LFC would like to be able to send those people a pdf of that information, rather than giving access to the whole wiki

  • Solutions:

    • Continue to build out the new styling, with printing in mind. Because a lot of what we need is hand in hand with formatting of proposals in general to look good, the new styling is a natural place to put this functionality.

    • Create a way for them to create a long wiki page with many #tdcrender tags in it for them to print to pdf. A little training on how to build those, but then they can create the page to their liking.

    • Look into the book creator and update to use print from chrome rather than from the mwlib library. So the same collections interface gets to be used, but we handle the rendering. This could, under the covers, use the above

  • Issues:

    • If we're rendering, page numbers get lost, for creating a TOC at the beginning of the book

• Uploads

  Jeff signed on to say that the major need to be solved here is when a plethora of new documents is coming for a number of proposals after the initial rounds are completed.

  The big noise around it right now is the 100&Change 2020 competition, which has a lot of new information coming in in the form of outside documents.

  • Solutions:

    • Create general upload area. But this has various problems, mainly in how these documents are permissioned. For instance, the workflow would be to create a page where the user can upload the document, while specifying what proposal it needs to be attached to, as well as what column it should look for for permissions. Then, inserting it into the proposal at the right place is challenging because the templates need to be edited.

    • A second solution is that previous to the upload, we add a field to the spreadsheet, like the LFC Analysis Fields, and put it into the template somewhere. Then, when the spreadsheet is absent, and upload button appears that attaches to that column, and the upload is only there for people who have permissions to it.

    • While both of those solutions solve this issue, it may not be truly necessary, as there's only 6 proposals, and all the pdfs will be received on December 11th, with no immediate need to get them on the site. That means we can just take care of it from the backend.

• Logins

  For Climate2030, and for all competitions, the question is what to do about accounts that require local logins, such as shared accounts. It's noted that no one likes that these accounts exist, for all the obvious reasons.

  Because we want to automatically use Okta to reduce confusion for normal users, we will always redirect to Okta. However, we need to write a new page "locallogin.php" that will redirect the person to the login page with a flag set such that they can log in locally.

  They will need to use this page each time they want to log in, after the wiki logs them out. This may actually be a boon as it will disincentivize people from using these kinds of accounts.

2020-11-19 11am CT Regular check-in meeting.

Keith, Regina, Jeff, Frank, Mike, Karl

• Resolving some authn/authz questions about Okta groups.

  (The meeting started early with Keith, Frank, and Karl discussing some Okta group and authentication/Authorization issues.)

  First, terminology: "chiclet" == "competition" == "application".

  Each user is linked directly to a competition (chiclet). Also, independently of that, users are assigned to groups in Okta. So whatever groups a user is a member of, those are the groups that user is in in for the competitions that they have access to.

  Now, although technically Okta can assign a group itself to a chiclet, we don't want to do that for most groups. Except, we do want to do it for the two groups "LFC Staff" and "LFC Torque Admins", because obviously people in those groups should have access to all competitions, so it's easier to just assign those two groups to all competitions instead of assigning those users on a per-user basis.

  Immediate action items:

  • Allegra gets LFC DM, and gets assigned to ECW2020.

  • Jeff's new test gmail address goes into LFC DM, and gets assigned to ECW2020, to test out Allegra's view.

  • For LLIIA2020, undo the link between LFC DM group and the LLIIA2020 competition, and then add user Matti to LLIIA2020.

  (Keith did most or all of the above during the meeting.)

  Frank notes that the the "Board Members" group might be assigned to 100Change2020. We need to get that cleaned up.

  TODO: Karl to send Keith and Chris the link to the canonical list of groups. Karl also to dig up Chris's recent email that gives the current State of the Onion about all Torque-related groups, and follow up to it with any needed instructions for fixing the world.

• Quick review of in-progress Global View

  • DECISION: No, we don't want TeamComments.

  • DECISION: Yes, we do want want attachments.

  • GUIDANCE: Usage mode will generally to filter by competition on a per-task / per-action basis. I.e., let's not build a modal interface where you set up your "which competitions to show/hide" filter once at the beginning of a long work session and then work within that mode. Instead, offer the ability to quickly filter a given action or set of search results on a one-off basis.

  • Karl wants to change the text "Signing in to Global View Wiki"

    This is from Okta, before logging in. Let's to change the wording to not say "Wiki", because from the users' point of view these are competitions, not wikis.

  • Stray <teamcomments/> tag underneath Snapshot box.

  • Budget table bug. See GVLoneStar2020 : 312 for an example.

• Big finalist evaluation process is coming up for 100Change2020

  The MacFound Board will soon be looking at 100Change2020 finalists. A pile of diligence is going to come. We'll be getting at least one big PDF from each applicant, plus maybe a few littler PDFs and other supplemental things. Material from the 6 finalists is expected to come on Dec. 11th.

  Highest priorities:

  • Self-service upload of attachments.

  • Ability to embed a PDF document in a page.

  • Printing: needs to be stable and look good.

  With the first two items, then they'd be able to upload an attachment and see it displayed on one of the evaluation tabs. Then the printing should just be "click here" to print the entire revised proposal and evaluations in one step.

  (The printing process for Lonestar was no fun: took a bunch of Word docs, jammed them into the wiki in wiki format, made edits, and then printed. It was cumbersome and one-off. We want to avoid the printable-Word-to-unprintable-wiki path -- that's not a happy path.)

  There will be a bunch of new tabs on the finalists's proposal pages.

  Then we want a table, with one row per each finalist proposal (so, e.g., 6 of them, for 100Change2020, to be selected from among in March of next year). Each finalist is submitting a revised proposal, and each will get a bunch of diligence. Some of that diligence will come in PDF form, some in CSV form. The table should summarize that diligence and link to it, where it be page or tab. See https://torque.leverforchange.org/100Change2020/index.php/Lists for an idea of where things are going.

  For each proposal, we should extend the original proposal page w/ a set of tabs: legal analysis, financial analysis, etc, etc.

  The "revised proposal is totally self-contained". This means don't shadow through any fields from the original proposal. People can go look at the original if they want to get at those fields. E.g., the revised proposal is the second tab, analyses are subsequent tabs.

• Jeff and Frank need to chat about Climate2030 login accounts.

  ECW2020 (for example) doesn't have any button at all for local-login, and Frank would like to make that standard, but there've been some complications re Climate2030, where apparently two local-login accounts have been created, albeit not by OTS, so OTS doesn't have the passwords or anything. Frank knows the details, and wants to discuss this with Jeff.

  Karl has sent them a reminder to schedule this conversation:

  From: Karl Fogel
  To: Jeff Ubois, Frank Duncan
  Subject: Discussion about Climate2030 local-login accounts.
  Date: Fri, 20 Nov 2020 00:06:42 -0600
  Message-ID: <[email protected]>
  

2020-11-17 1:15pm CT Frank/Karl Global View check-in.

Ready for demo, though Karl asked Frank to change the styles of the items in the TOC list if it's not too hard to do so before Thursday:

• ORG (non-linked)
• TITLE + REVIEW NUMBER (linked)
• COMPETITION-in-parens (non-linked)

We expect that LFC will have more to say about the TOC format, of course.

There were some minor search bugs (noted in this Zulip thread, but we don't have to have those fixed for the demo -- let not the perfect be the enemy of the good and all that.

2020-11-09 4pm CT Frank/Karl check-in.

• General discussion about request prioritization.

  The amount of custom data-slinging and presentation work is increasing, but we're also getting faster at it. A useful data point: Ingesting those new one-off budget tables that Jeff sent took nearly as much time as setting up a whole new competition (ECW2020).

  LoneStar2020 budget tables: we should mention that setting schedule expectations clearly will help a lot. E.g., OTS came out of Thursday's meeting thinking ECW2020 setup took priority even over the Lone Star budget tables, but that may not have been correct.

  Styling/presentation work is very interrupty. It's never hard, per se, it's just unpredictable time-sensitive. "The hardest part is parsing the need." Three different people email; sometimes they're emailing about the same thing, sometimes they're not. The project management part takes some time. It's not onerous or anything, but it just takes time.

• What's on Frank's plate.

  • Finishing up Global View, and deploying the GV demo.

  • Upgrading production sites based on recent refactoring:

    This includes, but is not limited to:

    • Upgrading MediaWiki instances

    • Some changes to MySQL (but note we are not switching to PostgreSQL right now; that's more of a project and we're allocating time for it as such)

    • The "lfc" -> "100Change2020" name change & forwarding.

  • Lots of little things.

    E.g., updating the memory limit (i.e., porting production hot patch over to ansible).

• What's on Karl's plate.

  • Review Mike's draft new stylations (did this later).

2020-11-05 11am CT Jeff/Regina/Frank/Mike/Karl Regular check-in meeting.

Everything below has been incorporated into the LFC Torque Feature Requests and Roadmap document as needed, but I've left a lot of detail here too because we covered a lot of ground in this meeting.

• ECW competition arrival, and making it look good.

  ECW (when it arrives) and LoneStar (see below) get top priority.

  We'll give ECW the new look and feel from the get-go.

• LoneStar2020: some final updates before it goes to them for a decision.

  LFC will send CSV files (or maybe multi-sheet spreadsheets) to OTS, and we'll get them on to the "LFC Analysis" pages.

• Handling proposals that get revised in the semi-finalist stage.

  Once a competition gets down to semi-finalists, they get to work with an army of consultants on improving their proposal and adding information. This only happens to 5-10 proposals per competition.

  (Jeff will send OTS the written guidance he has about this process.)

  Regina will talk to Kristen and see if a consistent CSV format can be imposed on those armies of consultants. (Karl will follow up to Regina's email thread about this; see her forward message from Kristen in "FW: Donor Due Diligence Info--wiki conversation".) Regina would strongly prefer to just enforce input standards, rather than have us deal with all sorts of ad hoc documents coming back and having to somehow get integrated into the semi-finalist proposals.

  On the implementation side, we discussed the possible route of just making an entirely new proposal entry for each revised semi-finalist proposal, e.g., with a review number that starts with "sf-" or something. The new revised proposal would point back to their original proposal for reference & comparison.

  Note that there will still be some new attachments coming in for semi-finalists, no matter how CSV-y the overall process is, so this raises the priority of the upload UI feature (discussed more below).

• Multi-competition orgs CSV etc.

  Generated new CSV using the new open source code for this and sent it. We can regenerate a new CSV report at any time as new competitions come in.

  We'll put that CSV up as a wiki page in Global View once Global View launches.

• Look-and-feel redesign status update.

  Coming very soon. Mike is working hard on it. Will show preview as soon as we have it, and ECW will get the new design.

• The "lfc" -> "100Change2020" rename (and redirect) will happen Saturday.

  Frank's deploying a lot of stuff on Saturday, actually, and this long-awaited name consistification will be part of that.

  (Technical note: we'll do the redirects at the Apache level.)

• Global View.

  Frank will set up Okta for Global View with MacFound IT.

  The two competitions first shown in GV will be LoneStar and LLIIA2020.

• Per-user proposal access restrictions.

  3rd-party evaluators often need to have access to just a subset of proposals in a given competition. Amazingly, we completed the technical designd work right here in the meeting and decided how to implement this (Frank got inspired):

  On the TorqueConfig:MainConfig page of a competition, in the "Permissions" table, just list a specific user by username, as if they were their own group.

  In that user's row in the "Columns" column, give them access to whatever columns they should have access to, that is, by referring to the appropriate page that lists columns (usually this would be just the standard TorqueConfig:ResearchPartnerColumns page).

  However, over in the "Proposal Groups" column, list a new page, say, TorqueConfig:JaneDoeProposals (instead of the usual TorqueConfig:ValidProposals), and of course that new page will just have the proposals that Jane Doe should be able to see.

  On the back end, when we see that a user's name is present in the leftmost column of the "Permissions" table, then we automatically use that row's permissions for that user. We do this by creating a MediaWiki group with the same name as the user (or maybe we'll have a certain prefix on that group name, like "LFCRRPJaneDoe"?).

  Meanwhile, MacFound IT will put that user into the special group LFC Restricted Evaluators, so that if Jane Doe logs in and her name is not present in the "Permissions" table, then we know to fail over to zero access -- she can't see anything (rather than the alternative, which would be to see all valid proposals, if she defaulted to regular LFC Research Partner).

• Prioritization conversation.

  1. Self-service uploads

     (And just put them always in the Attachments section in the Snapshot box.)

  2. PickSome improvements

  3. Switching user identity:

     Defer until after new redesign, as we're not sure we'll still need it after the redesign is done.

• Exploring the GuideStar API

  GuideStar has APIs.

  OTS to explore using them to fetch information about organizations (probably only when we have the org's EIN), so we can present that information in some convenient way in Torque. E.g., via a popup infobox when you hover over the organization’s name.

2020-11-05 9am CT Frank/Mike/Karl check-in on Global View.

Good conversation, but happened already too long ago for Karl to remember what notes he wanted to take here. Anyway, we checked in.

2020-11-03 Mike/Frank/Karl Global View check-in.

• Setting up the Global View demo.

  Frank will start setting this up right now, treating it as highest priority. We'll all check in tomorrow morning at 11am CT / 5pm UK.

  We'll put it at the expected production URL for Global View. 100Change2020 and LLIIA2020 are the two competitions for the initial demonstration. For the demo, this will involve making separate copies of those two competitions, because we don't want to undertake the process of upgrading all the production wikis to the new PostgreSQL back end right now (that's a separate step to be taken later once we're deploying GV for real).

  Proposals will be visible directly in Global View. I.e., you don't pass through to the original proposal's wiki to see that proposal in Global View, instead you see it directly in Global View.

  (Of course, what Global View shows you may be restricted in various ways, depending on who you are. This is because someone might have, say, the LFC Evaluator role in Global View without otherwise having explicit access to individual competitions. Karl is still a little bit confused on the precise semantics of this, by the way, but Frank and Mike seemed to be in complete mutual agreement about it, so Karl will see if he can think his way out of his confusion before asking any more questions about it.)

  The URL to a proposal will be "title_(competition:review_number)", or something like that -- here Karl just typed out what he thought he heard Frank suggest, but Frank please go with whatever you were thinking; it'll be easy to tweak if we want.

• In general, let's give demos an up-to-date LFC look and feel.

  We'll deploy our demonstrations from torque-sites instead of from the torque example site, because right now demos (even when they're purely internal) are always ultimately for LFC, and therefore we should be looking at the latest LFC UI/UX.

• In the example wiki, why are Topic and Population TOC pages empty?

  Answer: most likely because the corresponding templates either don't exist or don't have the right names. Mike will debug.

• Various issues with editing; Mike will look into these.

  • Editing fields doesn't work.

  • Section titles are editable but shouldn't be.

  • Tried to edit the "Review Number" field (in proposal 243), got "undefined" as the value.

2020-11-01 Authentication, passwords, MySQL, etc.

• DECISION: Switch to different DB creds for each competition.

  Right now every wiki (competition) uses the same DB creds to access MySQL. Although the security risks of this are fairly low, given our threat models, still it would be better to have separate creds for every competition, so we're going to switch to doing that as part of the current ansible refactoring.

  DB username will be CompetitionName_rw ("_rw" standing for "read-write"; we might later have "_ro" for a "read-only" DB user, e.g., for backups).

  (Note: Eventually we'll be changing our MediaWiki instances to use PostgreSQL instead of MySQL, to match Torque itself, but that's a project for a future point and is not related to this topic. More about that in issue #57.)

• TODO: Karl to ping Jeff about upcoming competition.

  To discuss threat model questions.

2020-10-22 Frank/Karl discuss upcoming table-ized TOC layout.

DECISIONS:

• Columns from left to right are: Organziation, Title, ID #, and Rank.

• The Title column will be the link to the proposal.

• Right-justify the numeric columns (ID # and Rank).

2020-10-22 Frank/Karl chat about API usage, groups, etc.

• Need to create a group that works cross-competition and shows all proposals.

  Long discussion about how our so-called "permissions" system is really expressing "permprefs". It's not only about what you can access, it's also about who you are and what your common use case or access mechanism is: API users are different from LFC staff. This is because there are often things you technically have access that you still shouldn't see by default in TOCs and other places where Torque is determining what's presented (e.g., just because you are allowed to see invalid proposals, say, or non-finalist proposals, doesn't mean you should ever enounter them in normal workflow).

  Given this, for API users we'll create permissions groups that have the API_ prefix. Right now that's going to be as follows (some will need their named changed over from a legacy group that was created from before this naming convention was established):

  • API_KFG (MIT Knowledge Futures Group)
  • API_ForumOne (new name for group "ForumOne")
  • API_Candid (new name for group "TorqueAPI")
  • API_OTS (Open Tech Strategies)

  We use underscores in in our portions, and may inherit CamelCase from the appropriate native short-form of someone's name but otherwise will avoid introducing it ourselves. E.g., ForumOne gets "API_ForumOne", but OTS is "API_OTS".

  Frank notes that we'll need to create an all-proposals page for every competition.

  Frank will also do some ansible re-organizing as a prerequisite to standardizing these new permissions groups, so that we have less of "say the same thing in N different places" going on.

• New skin will get its own repository: torque-lfc-theme

• We theorize that past API speed issues are likely due to permission calculation. As Karl uses the API, he'll check in with Frank and we'll solve problems as they come up.

2020-10-22 Jeff/Regina/Frank/Karl Regular check-in meeting.

Everything from this meeting is reflected in detail in the LFC Torque Feature Requests and Roadmap document. Below is just a summaray:

• DECISION: Always upload all submitted proposals.

  Both valid and invalid proposals should be included. This is actually what we already do; it's just a matter of documenting it as a policy and ensuring that the API can take advantage of it.

• OTS to deliver a more complete multi-competition org report.

• OTS to handle Emma Poole's request (see "One More Wiki Question" thread).

• DECISION: Yes, when recording "done" things, include activities things like Karl's meeting with SJ Klein and James Weis at the MIT Knowledge Futures Group.

• Some day LFC will start providing "phase" information for proposals.

  That is, what phase of evaluation did a proposal make it to (e.g., semi-finalist, finalist). Right now, we don't have that information represented in any consistent, formal way -- it's not a column in a spreadsheet or anything. Once we have have a formal representation for it, a certain class of queries will become possible that are not possible right now.

• Regina will help steer OTS's site-stylation questions to the right folks.

• Table-ized TOCs and table sorting + CSV exports coming RSN.

2020-10-14 Chris/Keith/Regina/Jeff/Frank/Karl Authentication discussion.

(See issue #76 for context.)

DECISIONS:

MacFound IT will set up a new "LFC Torque" Okta instance, and all Torque competitions will use it as the only way interactive users log in.

(Flavor notes for Chris and Keith: the new instance is "more of an app identity provider, not an enterprise SSO instance".)

Torque will use only this new LFC Torque Okta instance, and will stop using the current MacFound Okta instance. Torque will also stop allowing wiki-based local-login (i.e., username/password accounts) for interactive human users. Thus, Torque competitions will no longer have a big blue login button on the front page. Instead, if a user isn't currently logged in to Okta, Torque will just auto-redirect them over to Okta for authentication.

External (i.e., non-LFC) users of Torque will have Okta accounts in this new instance. Jeff will have Okta's "App Admin" and "Group Admin" powers in the new instance (and so will Regina, if only she can accept responsibility along with power).

For internal LFC users (e.g., Regina, Jeff, Jenna, Muhsin), regular MacFound Okta will delegate to this new instance, meaning that those people will have to deal with at most one extra click from time to time when authenticating.

Regarding API access:

Organizations that access the Torque API won't use Okta for that. They will continue to authenticate as they do now (which is something similar to username/password). OTS will make sure to choose secure passwords, and make sure those passwords can only be reset by OTS and not by the clients. OTS will do an audit of current API users to ensure this is the case for all of them.

2020-10-08 Jeff/Regina/Jenna/Frank/Karl check-in.

• Setting up the upcoming "Equality Can't Wait" competition.

  • Is the competition itself confidential?

    No.

  • Is there a competition logo?

    Yes. Jenna sent it during the meeting.

  • What should shortname be for this competition?

    ECW2020

  • Okta vs local login? Both? Some other SSO service?

    Just local login: username / password for all users.

  • What groups/roles will be accessing this competition's data?

    • Decision Makers
    • LFC Staff
    • LFC Evaluators
    • LFC Research Partners

  • What permissions do the groups need, especially regarding attachments?

    Just normal permissions. Use LLIIA2020 as an example.

  • Which proposals (rows) should be included?

    There will be a "Valid/Invalid" column; just use that.
    (This is becoming standard.)

  • How should proposals be sorted initially?

    By organization name, same as Lone Star.

  • What categorizations do we want to have Tables of Contents for?

    • Geography: state and city (this competition is just within the U.S.). Split these into current and future, though.

    • Strategic Approach

    • Number of Employees

    • Budget

    • Priority Population

    • Issue Area (but only if this response has meaningful differences between proposals).

  • Is any review/evaluation/ranking data included at competition creation time?

    Nope.

  • Will review spreadsheets be coming later?

    Yes. Peer Review coming on Dec. 1st.

  • How many different stages of review will there be?

    Peer to Peer, then Expert.

    (Which is the standard nowadays.)

  • Do we know what followup information (budget tables, etc?) might be coming later?

    We don't know yet.

  • Any special instructions regarding attachments?

    Nope.

  • What plugin-based features will be enabled?

    • SimpleFavorites
    • TeamComments
    • PickSome (number of choices is not known yet)

• Lone Star.

  We already have Peer Judges' data, but other judging data is coming.

  We'll use the new separate tabs for analysis data. Jenna confirms that the tab structure is good:

  Proposal / Judge Comments / LFC Analysis

  However, she'd like three minor changes to the "LFC Analysis" pages:

  • Add a Solution Category ranking.
  • Add one box about donor's relationship with the grantee.
  • Add a section in Financial Overview about previous funding.

  She will send an email with details.

  Expect a gnarly week starting around Nov. 1st, as judging data comes in. Frank will try to be extra available on Nov. 4th and 5th.

  LFC needs a commenting view such that Decision Makers can't see comments.

  TODO: Frank will make that adjustment for Lone Star.

  (Note that if that needs to be done elsewhere, some extra work would be involved. Frank and Karl discussed it a bit in this call: the shortest route would be to put comments on different pages -- e.g., Decision Maker comments go on the proposal page, while LFC comments go on the "LFC Analysis" page -- because then the two instances of Comments can be permission differently.)

  Regarding printing:

  TODO: Frank to port LLIIA2020 printing improvements over to Lone Star, to make sure "LFC Analysis" pages print well.

• ETA for updated Demo Wiki.

  Frank will send everyone an announce when this is done.

• The generic ICONIQ login.

  This is done on LLIIA2020.

• Discussion about role mapping.

  We're getting revised proposals in some competitions, for a stage 2, now. The evaluation process for stage 2 will be different. LFC will want to hide comments from some evaluators.

  • LFC Research Partner: Limit access to comments made by donors.

  • LFC Evaluator: Let them see those comments, as LFC Evaluators are closer to staff.

  Ball is in LFC's (specifically Jeff's) court on this for now, but OTS will be ready to make these changes as needed.

• Let's have a regular bi-weekly meeting.

  Regina will send out a calendar invitation to everyone.

2020-10-08 Frank/Mike/Karl Global View and Search check-in.

Progress is good. Mike is choosing to put some data in files -- that is, PostgreSQL file type column instead of string type, e.g., templates, since they can get large-ish.

We noted that all data (except edits) can be re-created by just re-running the ETL pipeline. But Mike should wait until tomorrow to run it, since Frank is almost done refactoring the ETL code!

Once the new ETL pipeline is ready, Mike should become as comfortable as Frank at running it.

Global TOC is still the first user-visible goalpost. We'll meet next Tuesday to check in on it, and Mike will let us know if he gets it done sooner.

2020-10-05 Frank/Mike/Karl Global View and Search check-in.

Yaxel's PR made some progress on converting stuff to Django. Mike has been finishing that and can import a spreadsheet into the database. He's now debugging the API endpoints. His current high-level todo list is:

• Fixing API endpoints.
• User testing.
• Performance work.

But that all just gets us to the current Torque functionality, operating with a PostgreSQL database backend instead of in-memory spreadsheets. How will the new Global View features work?

Answer: Global View is a wiki that just happens to have access to more than one competition. The trick is to get the tdcrender tags to use the right template / configuration for each competition. That link between the Global View wiki and the various competition wikis still needs to be designed and built. For v1, GV will just piggyback on the search caches and templates and permissions for each wiki.

DECISION: We accept that certain things will be implemented in Python rather than in the database queries -- that is, for performance reasons we can't restrict ourselves to working purely through the ORM. Sometimes we'll need to collect a large set of results (perhaps in memory, or perhaps streamed through a cursor) and then do further filter in Python, because there will inevitably be cases where our logic (particularly around permissions) will be much more efficient if done as Python code than as relational joins in a database.

First deliverable will be a Global View TOC. We'll check in on progress on Thursday, 8 Oct. It's not expected to be ready by then, but Mike will be better able to estimate where we are.

Once the underlying infrastructure is done and can handle the basics (displaying an all-proposals TOC, visiting a proposal from any competition, and doing searches), rolling out any further Global View features will be pretty easy.

2020-10-01 Frank/James Docker discussion

Right now we have a large duplication of ansible file, that needs to be refactored. Do we use Docker?

Docker is great for upgrading, and for deploying similar systems that are just configured via environment variables. The competitions for lfc fit that profile, and so it's a natural move to use docker.

The process would be:

1. Create a docker file for our competitions that extends the mediawiki docker image (https://hub.docker.com/_/mediawiki)

2. Add all the extensions, and basic configurations (like permissions) to this base image.

3. Create an ansible file, or scripts, that configure that docker image for a given competition (name, extensions enabled, etc), with maybe some extra php code as needed.

4. When upgrades need to happen, deploy those upgrades from within the torque-sites repository, potentially with rebuilding images.

One concern is that docker is not a current OTS deployment method, but that looks to be changing, and it's become a general skill many people would have coming into the organization.

Another concern is how heavyweight these images would be. Right now, the mediawiki images do some kind of http server running, but the question is how many of them can you spin up on one machine.

Right now, it's not necessary to dockerize torque itself, but it might not be a big lift as the server is so small. See https://github.com/OpenTechStrategies/torque/issues/37 for more discussion on that.

James to talk to Karl about this, and put it on the roadmap if it seems the correct path. James to also do some basic research into how resource intensive the base mediawiki docker image is.

2020-10-01 Jeff/Regina/Frank/Karl Broad-ranging discussion.

• Discussion based on feedback from awards directors.

  Overall question: "How do we best explain what we have?"

  LFC is going to make an introductory video per competition, with some stock footage re-used from the DemoView competition.

  TODO: Frank will put the new sample data into DemoView, as one outcome of the almost-done ETL refactoring.

  Let's solidify our canonical "menu of offerings". The canonical list we tentatively came up with in this meeting is:

  • Favorites
  • Picking and Voting
  • Comments
  • Edits (by LFC Staff)

  (Note this is related to the Questions to ask before creating a new competition.)

• Implement the point-distribution voting feature.

  TODO: It's time to implement voting feature whereby each Decision Maker gets X points to spread across Y proposals. Karl will put this on the LFC Torque Feature Requests and Roadmap and we can check in about its priority at our next meeting.

  (C.f. ElectionBuddy https://ElectionBuddy.com/ the service that Regina used when the MacFound Board was deciding 100Change2020.)

• Make tables be sortable in-place and downloadable as CSV.

  TODO: Frank to make all tables have class "wikitable-sortable".

  TODO: Frank to explore and install the ExportTables extension if it looks good, so that we get "download wiki table as CSV" functionality.

  Some discussoin about about generating tables from proposal data.

• Make the "All Proposals" page be a table instead of a list.

  Columns Org, Proposal Title, Application ID, Rank

  All other TOCs will remain lists for now.

• Improve visual styling

  Muhsin and Jenna are showing this off; it would sure help to have better visual styling.

  Frank pointed out that there's an old todo that we never really explored of creating our own style guide, and even tweaking individual competitions to look like their upstream competition site.

  TODO: Start with an overall improvement, using LFC/BSN sites as a reference, but not customized per competition.

• ("medium priority"): Allow LFC Staff to flip to Decision Maker, etc view

  Dropdown menu of roles to flip view to, so LFC Staff can see the competition as others see it.

• WMF Grants: we'd planned to apply for some -- what's the status?

  TODO: Karl to talk to Mike about helping with this.

• Common Grant Application

  Other foundations (Gates, Ford, MacArthur, et al) are talking about the idea of a Common Grant Application system, similar to the Common Application that some colleges and universities use.

  There are already initiatives:

  • ActionForImpact (Gates)
  • Covid Philanthropy Commons (Funding Research Group?)
  • JustFundMe (?)

  See this email from Jeff:

    From: Jeff Ubois
    Subject: Platforms 
    To: John Mohr, Karl Fogel
    Date: Wed, 30 Sep 2020 15:47:22 +0000
    Message-ID: <[email protected]>
  

  TODO: Jeff to set up meeting about SSO and this

• We need a first-class user management solution.

  Control of per-user groups (access controls), different groups per user per competition, authenticating users via SSO (including API users), etc.

  DONE: Karl to send out email(s) about the issue #76 plan:

    From: Karl Fogel
    To: Jeff Ubois, Keith Krellwitz, Regina Shoykhet,
        Muhsin Hassan, Jenna Schornack, Frank Duncan
    Subject: Planned user account management improvements for Torque.
    Date: Fri, 02 Oct 2020 10:18:46 -0500
    Message-ID: <[email protected]>
  

  and

    From: Karl Fogel
    To: Jeff Ubois
    Cc: Christopher Andreen, Keith Krellwitz, 
        Frank Duncan, Regina Shoykhet
    Subject: Re: Discussion re: account management, API
             access to proposal data, and marketplaces
    Date: Fri, 02 Oct 2020 10:22:23 -0500
    Message-ID: <[email protected]>
  

• Competition is on the horizon -- be aware.

  The Submittable + Airtable combination is formidable. Also, as always there is also pressure to just build systems on Salesforce. Torque needs to have clear advantages over either of these routes.

2020-09-28 Jeff/Frank/Karl SSO etc discussion.

• Some accounts will need access to multiple wikis.

• Should people be able to sign up for wikis, w/ approval.

• John Moore / Chris / Keith

  Can Okta do this?

• Shared ICONIQ account question.

  Yes, this was done. "ICONIQ" account created. (When you think about it, Candid's API access is also effectively a shared account.)

  DONE: Karl documented this policy in commit 55856b823c.

• Frank fixed printing

  TODO: Check whether to restrict it to just analysis pages or let it be wiki-wide general CSS.

• Disabled edit for DMs on LLIIA2020.

  TODO: Will get propagated to other wikis.

2020-09-24 Frank/Karl design discussion

Original idea: torque does not contain data, torque is a front for data that is provided to us. We'd have the spreadsheet on disk, then suck it into memory. So data lives in spreadsheets, permissions live in wikis, and everything else is a cache.

Then search got involved, necessitating a new cache. Then we did edits... and Global View is coming... So now we've evolved to "Torque is no longer a cache, it's a data repository."

Possible paths forward:

• Static structure: encode business logic in core

  Create a rigorous definition of what a Proposal is, and do things based on that definition.

• Dynamic structure: flexible data engine for wikis.

  Do not rigorously define what a Proposal is. Treat Torque as a general-purpose data engine for wikis.

Costs of dynamicism show up in:

• TOCs
• Editability and validation
• Search, and faceting thereof (n.b. intertwingulated with permissions)
• Configuration (templates)

For example, right now if you do an edit on a field that's a TOC field, it won't automatically update the TOC. In order to get that, we'd have to enhance the data-description language.

DECISION: Nevertheless, dynamic is the way to go. It means we incur a fixed overhead on development, which is noticeable, but we retain flexibility not just for other possible non-proposal uses of Torque but for unexpected feature requests from LFC.

• Agenda for upcoming conversation with LFC SSO, managing own accounts, changing passwords.

• Frank's schedule through October:

  • Out Fridays until 3pm, at least through October.
  • Mon, Tue, Thu will be best for meetings.
  • Wednesday is merely okay.

2020-09-21 Frank/Karl Check-in

• Climate2030: up by end of today or tomorrow

• Karl emailed LFC regarding trying out the "LFC Analysis" pages soon.

  Basically, please don't wait until right before the meeting with donors, because this is a new feature and if anything goes wrong we want to have time to fix it.

  DONE, in this email:

    From: Karl Fogel
    To: Jeff Ubois, Jenna Schornack, Muhsin Hassan, Regina Shoykhet
    Cc: Frank Duncan
    Subject: Climate2030 up by EOD tomorrow; plus, "LFC Analysis" thoughts.
    Date: Mon, 21 Sep 2020 12:51:50 -0500
    Message-ID: <[email protected]>
  

• Made an example ETL pipeline on top of the new sample data from Yaxel.

  See the 36-sample-data branch right now, but Frank will merge it into master soon anyway.

  This will also merge PR 43.

• DECISION: Change master branch to main in all our Torque-related repositories:

  • torque
  • torque-sites
  • PickSome
  • SimpleFavorites
  • TeamComments
  • ActivityLog

• DECISION: Make a GenericDemo site using this data.

  We are not replacing the LFC DemoView instance right now. We'll show LFC this new site and then they can decide.

• ETL refactoring is up next.

• Review the feature checklist for issue #32: editability improvements.

  Frank and I brought this checklist up to date.

  Only "Editing validated lists" (not so urgent) and "Protect against the usual concurrent-edits race condition" (somewhat urgent) are left now.

• Frank merged PR 41 during this meeting.

• PR 44 is not ready yet.

  Frank and Karl have set a dedicated meeting on Thursday to discuss this, along with more-general Torque data design questions.

• Is "Better integration/display of Comments" addressed by "LFC Analysis" etc?

  Yes, we hypothesized. Karl moved it to the "Done" section in the roadmap doc.

• Go over the remaining editability checklist.

2020-09-16 1:20pm CT Jeff/Frank/Mike/Karl LFC Analysis pages and editability

(Note: on 2020-09-21, Frank mentioned that everything decided below, including the superseding decisions from after Muhsin joined, has now been done.)

• DECISION: Make a new authz group "LFC Consulting Partners"

  This one is like "LFC Staff" but it's for non-LFC-employees, and they won't have TorqueAdmin access. They have the DecisionMaker (non-Admin) view into the wiki, but they can see all information about proposals, and can see (but not edit) "LFC Analysis" pages.

• DECISION: Permissions for "LFC Analysis" will be as follows:

  • Everyone can see "LFC Analysis" pages.

  • Only "LFC Staff" has edit ability.

  • Note that some groups don't see ranks.

    (We already know who -- this is well-known and documented.)

• DECISION: Deploy "LFC Analysis" to LLIIA2020.

  More likely tomorrow morning than today, because it involves also deploying the new editability feature, of course.

• Frank will take care of the requested new user accounts.

  Four of them: three were already in Frank's queue, and the fourth is given here.

  Frank will make sure Jeff has a chance to test-drive the accounts before the real account holders are notified.

• Budget table spreadsheets will soon be on "LFC Analysis" page.

  Frank and Muhsin will work out how OTS gets the information; it's going to be spreadsheets of some kind. Note there will be no way to edit those tables in the "LFC Analysis" pages, of course.

• DECISION: Change "Page" to "Proposal" for proposals that have "LFC Analysis".

• Climate2030 data received; competition setup will be in next day or two.

Part 2, Followup with Muhsin

• DECISION: Budget table is being replaced by Financial Overview section, to be entered in through wiki edit interface

• DECISION: "LFC Consulting Partners" will have ability to edit LFC Analysis (Jeff was involved on this decision)

• DECISION: There will be a third tab "Evaluation" that has the Peer Review and Expert Panel comments. This will be for all of them

• DECISION: "DecisionsMakers" will only be able to see the 16 proposals for all TOCs and whatnot.

2020-09-16 11am CT Frank/Mike/Karl Feature and data design discussion.

Review of editability feature, especially on "LFC Analysis" pages.

Frank did some live-coding to make various minor adjustments:

• Made paragraph breaks work by using the replace function in Jinja templates to replace a newline with a double "
  ". This is magic that Karl had not been previously aware of. Search for occurrences of "replace" in this diff for details.

• Adjusted cell padding: now 5px from top and 7px from left.

• Moved the "[edit]" button to the lower left of each cell.

• Decided to leave the single-item lists in the lower table, because that's how they were in the original Word doc.

• Decided to leave the horizontal lines dividing the top fields, again because that's how the original Word doc is.

• Decided to leave field names in blue, after some experimentation.

  Even though that blue is close to the "I am a link" color, and these are not links, it's still visually nice, so let's leave it. If LFC ever wants clearer distinction from links, we can revisit this.

2020-09-15 Frank/Mike/Karl Editability UI and design meeting.

• Need more contrast between Save/Cancel buttons in editability feature.

  The two buttons should be more distinct: Save should be the big blue button (the clear default, appx 70% of the width) and Cancel should be the small gray or white button (appx 15% of the available width). The remaining width should be separating space between the buttons.

• Support MediaWiki syntax when editing.

  Paragraph breaks inserted by the user will be paragraph breaks in the result; asterisk-demarcated lists will be real lists in the result, etc. This requires a round-trip to the server and a full DOM refresh, but the user experience should be okay because the viewpane position on the page won't change.

  This change will mean that default text (i.e., text that's present only in the template, e.g., for fields in the "LFC Analysis" pages) will no longer be present in the text field when you edit. That's okay, in fact is even a desirable outcome. And naturally this will fix -- "for free" -- the bug whereby hitting edit and then canceling immediately would result in the default text being rendered in roman type instead of italic until you do something to refresh the page.

  This change also requires assigning the edit button to the editable element unambiguously in the template, which means we have to update all the templates where editing is enabled (just two competitions right now).

• Review of near-term priorities.

  1. Right away:

     • Mike to make the editability fixes discussed above.

       He expects it to be done by tomorrow's meeting.

     • Frank to set up the new 2030 Climate Challenge competition

     For now, no more work is needed on "LFC Analysis", other than to merge Mike's new editability changes as soon as they're ready.

  2. Next up:

     • Mike to continue on search and Global View.

     • Frank to ETL-ize the new sampled data for DemoView.

       Note this happens in torque not in torque-sites.

  3. A while later:

     • Frank to do the long-needed ETL refactoring.

     • Frank to incorporate org name into TOCs when printing.

       This needs to not affect page titles, so it will involve spelunking in the printing code.

Karl will update LFC Torque Feature Requests and Roadmap accordingly for all the above.

2020-09-10 LFC and OTS discuss review templates, etc.

Jeff, Regina, Jenna, Muhsin, Frank, Karl

• Login issues

  For now, we'll just try to anticipate problems and make sure to be ready to provide tech support around time of initial login. The recent redesign of the Okta-vs-regular login choice UI may help. Usually when there are problems it's just that the person clicked in the wrong place or didn't fully grok the instructions; sometimes it's 2FA-related; occasionally it's something we muffed.

• Demo of LoneStar2020 on Monday

  Jenna sent the three people who will be logging in on Monday will be DecisionMakers.

• LLIIA2020 ranking by judges

  Frank knows what this is and will do it.

• Set up DecisionMakers group for LoneStar2020 and LLIIA2020.

  Frank will make sure DecisionMakers group is set up for both LLIIA2020 and LoneStar2020, and coordinate with Keith.

• LLIIA2020 DecisionMakers will see just the Top 15

• LLIIA2020 review template

  Basically, implement it like a "Talk" page, but call it the "LFC Analysis" page. Have a template on it that matches the review template that they'd like to use.

  • Deadline for this is Sep. 16th/17th. LFC will be using it heavily starting the week of the 21st. (On the 15th they'll have the Top 15, then till the 24th to finalize.)

  • Separate tab for "LFC Analysis" page, showing template with fields, and Edit buttons for fields that should support editing.

    Each Edit button will correspond to a row in our DB, so everything will be logged as usual.

    Once we've captured that information from the "LFC Analysis" page, we can update the primary page template to display some of it (e.g., in the Snapshot box)

    As soon as possible, LFC will give OTS spreadsheets for the budget tables that need to show up on the "LFC Analysis" pages, and OTS will load them up. These budget tables are not going to be editable.

  • The "LFC Analysis" page will use the template Jeff sent, which Frank has, so even though Karl isn't sure what it looks like (and it's Karl writing these notes), Karl has complete confidence that everyone else knows what this means.

  • We may include links to the analysis page(s) from appropriate places in the TOC.

• Global view, search, API.

  We didn't discuss these in depth in this meeting, but there is much excitement over the upcoming Global View.

2020-09-10 Frank/Karl/Mike Global View internal design meeting.

• Started with mini-discussion about internal review interface

  Re recent email thread with Jeff, Muhsin, et al: how to incorporate internal review comments into something more like a Talk Page.

• Global view

  • See details in the Global View section of the usual place.

  • Mike to do some PostgreSQL FTS research and come back tomorrow with a more informed time estimate.

  • Frank to review Yaxel's PostgreSQL changes so far.

  • Frank to set up a basic Global View instance.

• Deploying editability

  • Server-side needs to check permission too
  • Still need to actually save (pickle) the edit
  • All the templates need to be updated
  • No approval UI yet, but that's okay

  Karl to ask Jeff which competitions should get editability, but suspects the answer is "all of them".

2020-09-08 Frank/Karl post-vacation catch-up.

• Login UI flow

  Make sure to loop James in on UI review.

• PostgreSQL: we'll use Django ORM with Flask.

• DemoView status and sample data

  It's now using its own independent Torque server.

  We used DemoView for recent editability feature demo.

  DemoView is still using live data, but will soon switch to fake sample data once PR #43 is merged.

• Frank will put commas in "Total Projected Costs" column.

  If field is numeric (i.e., can be parsed by float()), then we'll put commas in the amount here (as we do in the Amount column in the Budget Table); otherwise, we'll leave it alone.

• DONE: Right-align amounts on LLIIA2020 budget tables.

  Here, for example. Frank did this right before the meeting, in response to my email. Dang, that's fast.

• Global View

  Karl to schedule internal design meeting. DONE:

  From: Karl Fogel To: James Vasile, Frank Duncan, Mike Nolan Cc: Jeff Ubois Subject: Internal design meeting for LFC competitions "Global View". Date: Tue, 08 Sep 2020 11:48:17 -0500 Message-ID: [email protected]

• Geocoding, marker pins, etc.

  Karl to start Google Maps vs OSM discussion with Mike. DONE:

  From: Karl Fogel To: Mike Nolan, Frank Duncan Subject: Mapping in Torque: Google Maps vs OpenStreetMap. Date: Tue, 08 Sep 2020 15:19:18 -0500 Message-ID: [email protected]

• Organization duplication analysis.

  Back burner for now until Karl has chance to prioritize it w/ LFC.

• Frank will review PRs 41, 43, and 44.

• Frank will incorporate the new spreadsheet from Jenna into LoneStar2020

2020-08-19 LFC/OTS regular progress check-in.

Jeff, Regina, Jenna, Frank, Karl

(The LFC Torque Feature Requests and Roadmap doc is a useful reference for these meetings, as always.)

• Answers to questions about the Lone Star Prize competition.

  • Is the competition itself confidential?

    Nope, it's public.

  • Is there a competition logo?

    Jenna will send.

  • What should shortname be for this competition?

    "LoneStar2020"

  • Okta login vs local login? Both?

    Regular login only.

  • What groups/roles will be accessing this competition's data?

    We will set up all the standard groups.

  • What permissions do the groups need, especially regarding attachments?

    LFC will get back to us on this.

  • Which proposals (rows) should be included?

    LFC will get back to us on this.

  • Which columns are to be included and which are not.

    Don't include the "Participant Key" fields, they're long and pointless for normal people. Every other column can be included for the first draft; LFC will then review and let us know if anything needs changing.

  • How should proposals be sorted initially?

    Sort alphabetical by organization name.

  • What categorizations do we want to have Tables of Contents for?

    These:

    • A TOC page organized by "Solution Category"
    • A TOC page organized by "Current Location of Work" (by county in Texas)
    • A TOC page organized by "Future Location of Work" (by county in Texas)
    • A TOC page sorted by organization annual budget
    • A TOC page sorted by number of employees

  • Is any review/evaluation/ranking data included at competition creation time?

    We'll have P2P review data.

  • Will review spreadsheets be coming later?

    Yes, more review data will be coming later.

  • How many different stages of review will there be? (This is not always knowable in advance, and that's fine, but the more we know ahead of time the better.)

    2 stages: end of Sep we get P2P, end of Oct we get judges'/evaluators' reviews.

  • Do we know what followup information (budget tables, etc?) might be coming later?

    None anticipated.

  • Any special instructions regarding attachments?

    No, not at this time. Should be similar to LLIIA2020 in terms of audited financials attachments, MOUs, etc.

  • Will "Comments" be used?

    Yes, for DecisionMakers.

  • Will the "Pick Some" extension (e.g., Wild Card selection) be used?

    Not sure yet; don't enable for now, but this might chnge.

  • Will the "Simple Favorites" feature be used?

    Yes.

  Based on the above answers, Karl may reorganize and even trim our standard new-competition question list a bit. For some of those questions, we don't really need to know the answer before setting up the competition.

• Do we need to develop a Personal Notes feature (i.e., user-private comments)?

  DECISION: No, not yet. We may revisit this in the future, but for now we won't schedule it into the roadmap.

• Do we need audited financials and MOU attachments for LLIIA2020?

  OTS doesn't have them. LFC will let us know if they are needed, and supply them if so.

• Karl to make the "New Competition Questions" list more easily available.

  It's now linked to from the new "References" section at the top of the roadmap doc.

• Recent log-in issues.

  We discussed how to avoid Matti's experience being repeated.

  We also investigated Regina's issues logging into 100Change2017 via Okta.

  See the roadmap doc for more details about both.

• Re "LFC Evaluators" role

  See item "Check that LLIIA2020 handles the “LFC Evaluators” role correctly." in the roadmap doc.

• Upcoming new competition.

  See OTS internal ref:93afa164 for confidential information about an upcoming competition.

2020-08-19 Mike/Frank/Karl editability feature check-in

• Frank will complete the set up of DemoView for LFC meeting today.

  Will show editablity for a couple of regular text fields and a couple of lists. We'll also make sure logging of edits works.

  (UPDATE: Frank ran into problems. We'll sync up with Mike tomorrow.)

• See this checklist comment in issue #32.

  It lists other things that we discussed in this meeting.

2020-08-18 Mike/Frank/Karl editability feature and browser compatibility.

• See this checklist comment in issue #32.

  It lists things we discussed in this meeting.

• Mike will set up the editability demo on DemoView.

  Will just do a few fields now, to demonstrate editing of an entire text field, a list-type field, and maybe a span-type field. Will leave most of the template un-editable, and especially will not add edit buttons to fields likely to be problematic.

• See internal OTS rev r16327 for another topic we discussed.

  It's an addition to the onboarding checklist.

2020-08-17 Frank/Karl new competitions check-in.

• Reformatted budget data for LLIIA2020 came in.

  Frank will handle this and get the data into SVN.

• LSP initial competition setup.

  Frank will get the data into Subversion.

  Karl will ask LFC The Questions, CC'ing Frank.

• Frank has requested some changes in Yaxel's #39 and #35.

2020-08-14 Mike/Karl editability feature and browser compatibility.

Mike, Frank, Karl.

• See this checklist comment in issue #32.

  It lists things we discussed in this meeting.

2020-08-11 Frank/Karl 100Change2017 access and roles, etc.

• Adding modern access roles to 100Change2017.

  Karl has followed up in the email discussion about this:

  From: Karl Fogel
  To: Frank Duncan
  Cc: Jeff Ubois
  Subject: Re: Research Partner confusion
  Date: Tue, 11 Aug 2020 11:56:54 -0500
  Message-ID: <[email protected]>
  

• Getting Okta enabled for 100Change2017

  Frank will ask MacFound IT to create an Okta app for 100Change2017. He did so right after the meeting:

  From: Frank Duncan Subject: Okta Configuration needed for 2017 100&Change competition To: MacFound IT / DevOps Cc: Jeff Ubois, Karl Fogel, Regina Shoykhet Date: Tue, 11 Aug 2020 10:41:44 -0500 Message-ID: CAK=DgqdwOpcLGQKH4QTwghdicP21R0kiK-+-u=PkN09yHn1A_w@mail.gmail.com

  And depending on the outcome of the email thread mentioned in the previous item in these notes, Frank may also ask MacFound IT to grant the "LFC Evaluators" and/or "LFC Research Partners" roles to the appropriate Okta users. Once that's done, he can update the 100Change2017 user-group configuration and those users would then be able to log in and see the right things.

• Updating the look-and-feel of 100Change2017.

  Frank will update the look and feel of 100Change2017 to match the modern competitions. Specifically: give it a Snapshot box and update the formatting of the judging data.

• Frank reviewed Yaxel's PR #39 and PR #35.

• Karl will respond in the email thread about geography nomenclature.

  Frank alerted Karl to it in the meeting. Karl followed up right after the meeting:

  From: Karl Fogel
  To: Frank Duncan
  Cc: Muhsin Hassan, Jeff Ubois
  Subject: Re: [COMPETITION NAME REDACTED] Wiki Geography TOC
  Date: Tue, 11 Aug 2020 12:09:49 -0500
  Message-ID: <[email protected]>
  

2020-08-04 Jeff/Frank/Yaxel/Karl demos and roadmap discussion.

Note that many of the detailed outcomes from this meeting are recorded in the LFC Torque Features Requests and Roadmap document, and only referred to from here.

• Logging feature to be deployed.

  DECISION: Deploy logging feature to production for all competitions. Frank has confirmed that only LFC Staff and LFC Admins can see the logs page (other groups, e.g., Board Members, cannot see it).

  This is DONE as of the morning of 2020-08-05 (see here for details).

• Walk-through of new editability feature.

  The results of this walk-through are recorded in issue #32.

• Walk-through of new DemoView site.

  • DECISION: Show every feature in the DemoView site.

    Throw all the sinks in the kitchen on to the DemoView site, at least for now. If it ever gets too cluttered, LFC will let us know and we’ll adjust accordingly then.

  • DECISION: Keep the “Semifinalist Memos” page in DemoView.

  • Jeff may make a video to go with the demo site.

  • Jeff may ask MacFound IT for direct Okta admin capability.

  • Discussion of user/group management.

    We need the ability to add someone to specific competitions (e.g., LLIIA2020), and for that person to be a member of "LFC Decision Makers".

    However, we think that Okta can't have a given user be in a certain group for certain competitions yet not be in that group for other competitions. In other words, if someone is in "LFC Decision Makers" for one competition (that they log in to using Okta), then they're in that group for every competition to which they have access via Okta. Jeff is going to discuss this with Keith.

  • DONE (well, in review): Karl to put The Canonical List of Okta groups into this document. See PR #73. Karl will send Jeff a link to the appropriate Torque docs once this PR is merged.

  • DONE: Karl to mail Keith and Jeff proposing a set of demo users/roles.

  • IN PROGRESS: Frank to add “Torque Configuration” to the left-side menu panel, under “Tools”. In progress as of Wednesday, 2020-08-05; see PR #40.

• Various LLIIA2020 changes.

  See the "LLIIA2020 requests (as of 2020-08-04)" item in the google doc. We're tracking these requests there instead of here because we want to go over them at the next meeting, and that's the doc we'll be looking at during that meeting.

• Pseudonymous Comments.

  Frank will push the new Pseudonymous Comments feature out to all competitions (especially important to get it deployed to 100Change2020, a.k.a., lfc, since they're going to be using the feature right away), and enable the Pseudonymous-only Comments view for "LFC Evaluators" and "LFC Research Partners" (but make sure that a user sees their own comments as being by them). Yaxel will do code review; Karl will try to do some too. Code review should be completed by EOD tomorrow, so Frank can push on Thursday morning.

• Global View feature.

  We'll meet tomorrow to focus on this.

2020-08-03 Frank/Karl check-in.

• Demo site.

  Demo site is ready: https://torque.leverforchange.org/DemoView/ .
  I customized the sidebar.

  Frank will contact MacFound IT about getting Okta logins for the demo site.

• Pseudonymized comments.

  The design for pseudonymized comments is done. Frank is starting implementation now and expects to finish very soon (possibly today, but anyway days not weeks).

• LFC Evaluator role.

  The LFC Evaluator role is done, except for the pseudonymized comments part of course.

2020-07-31 Frank/Karl check-in.

• Frank will set up demo site.

• Frank will do the first draft of the pseudonymized comments. The hard part is actually coming up with stable pseudonyms.

• Frank reviewed Yaxel's PR #35.

2020-07-31 Mike/Karl editability feature UI check-in.

• Progress looking good!

• Discussed design for back-end representation and storage of edits. See commit 3f36624e7dee on branch 32-editability-feature, which Karl created for Mike to store his work on (i.e., it should be a continuation of the torque-edit2 branch in Mike's clone repository). Karl added a note to issue #32 to that effect.

• Discussed OTS preference for dev branches to live in the OTS repository.

  I.e., not in one's personal clone, though it's not a big deal either way, and see below for how this relates to SSH key policy.

• SSH key policy.

  SSH private keys that give access to OTS resources shouldn't live on machines we don't control, like AWS servers. This is related to the choice to use one's own clone to hold branches, since then one can have a repository-specific SSH key for one's own repository on (say) an AWS server and it doesn't matter for OTS -- we just review the PR when it comes in. Karl and James will discuss, refine, and document this policy (they did so right after this meeting).

• Preference to push to GitHub regularly. Karl and James will document this too.

2020-07-29 Mike/Karl editability feature UI check-in.

• Button code in template.

  We discussed the possibility of compressing the long button expressions into a shorter new jinja template code for buttons, but we decided to defer, since we don't yet know how many different types of button styles we'll need. We can introduce new template codes at any time, and furthermore it doesn't even have to be done all at once, so let's find out more about the problem space before we make this abstraction.

• Editing list-type items.

  Yes, just edit the full spreadsheet cell value as one text field, with the understanding that the user will need to preserve the newlines (e.g., in a list of cities). However, when it is a list-type item -- which we can determine unambiguously, as the spreadsheet itself uses row 2 to give type information -- we'll display a warning next to the edit form about how the newline-based separation has to be preserved.

• Document steps to remove login gateway.

  Once Mike figures out how to disable login (e.g., for demo sites), he will document the steps in INSTALL.md.

• Include log message in the overlay table that records edits.

  Karl has already updated issue #32 accordingly.

• Next checkin will be Friday morning.

  We'll do it early (3:30pm London / 8:30am Chicago). If progress is sufficiently far along, Karl will then schedule a demo with LFC.

• Mike was having some opass problems yesterday.

  Solved; we successfully debugged this.

  We also discussed setting up opass path completion in the shell. See utils/bash-completion in the OTS SVN tree for how to do it.

2020-07-28 Mike/Frank/Karl editability feature check-in.

We reviewed and discussed the user interface, which has made a lot of progress: the edit buttons now open up an inline edit form. We then discussed various UI design and implementation considerations. Our decisions are listed below.

• DECISION: Each edit button's position and styling will be controlled from the proposal template.

  The reason this level of control is necessary is the heterogeneity of fields on a proposal page. Some fields correspond to (say) a single paragraph of text from a single column in the proposal. Other fields, such as address fields, might correspond to an assemblage of data from different columns; for example, in an address field the "Chicago" and "Illinois" might actually come from different columns. Still other fields look like they're assembled from multiple columns but actually come from one column; for example, in a top-level "Comments" field there might be a subfield "Magnitude of Impact", which contains a bullet-point list of comments -- but those bullet points are all coming from one field, which has them actually written out as bullet points, and we need to be able to position an edit button so that it is clear that it applies to the entire field, not just to the first or the last bullet point.

• DECISION: The overlay table will live in memory the same way current Torque data does.

  This means we'll defer decisions about issue #26 ("Move spreadsheet storage to postgres") until later.

• DECISION: We settled on what fields the overlay "table" should have.

  Those fields are now listed in issue #32.

• DECISION: Ensure that data writes for the edit data are atomic.

  Atomicity in proposal data now matters for the first time, since these edits are effectively becoming part of the proposal data. This never mattered before because the only proposal data being written was the original spreadsheet data, and we could always just re-run ETL as part of the recovery.

  As long as we're making data writes of edit data be atomic, we might as well use the same functionality to make the original spreadsheet writes be atomic too, just for good form.

  (Note that features that have their own plugins, such as TeamComments, were using the database already, so they have atomicity and are not a concern here.)

• DECISION: Make the dev-demo wiki public and not require login.

  This is so we can easily show the in-progress feature to LFC.

Also, Mike experienced some problems with opass; Karl will debug, asking Mike for help reproducing the bug as necessary.

2020-07-27 Mike/Karl editability feature check-in

Another quick check in. Progress looking good; we made some more decisions about how the UI should work. See the next meeting for a more substantive report.

2020-07-24 Mike/Karl editability feature check-in

Just a quick check in. Progress looking good.

2020-07-23 Mike/Karl discussion of setup overhead

Some notes about things that could be improved in the dev setup process.

• Installation of MediaWiki itself could be automated

• SimpleSaml gets downloaded and unpacked, then a script is run. But something apparently failed.

• Are we getting third-party stuff from a stable place on a server we control?

• Manual creation of DB user in MariaDB / MySQL (That is, the user mw connects to the DB with.) Automated creation fails somehow? Anyway, ansible tries to run a script later on that tries to modify the DB and that script fails. Mike just blew away the user and recreated it with the right permissions, but obviously he shouldn't have to do that.

2020-07-20 Jeff/Regina/Frank/Karl near-term feature priorities

Note that much of the output from this meeting is in the Features Roadmap document.

• LFC Evaluators

  Discussed; see the Features Roadmap document.

• "Shareable" template to replace "Redacted"

  Discussed; see the Features Roadmap document.

• Demo Competition

  Discussed; see the Features Roadmap document.

• Improve the Comments display interface

  Discussed; see the Features Roadmap document.

• Revised proposals and proposal reviews coming in September.

  In September, we’ll get revised proposals and proposal reviews (various domain-specific analyses). These will be PDF documents, written by consultants who will want their formatting left as-is.

  For 100Change2020, the revised proposals come from the applicants, and are just big PDFs. Fortunately, there are only six of them. They’ll be significantly different from the original proposals, though.

2020-07-16 Jeff/Frank/Mike/Karl feature prioritization meeting

Outcomes from this meeting are all reflected in the Features Roadmap document.

2020-07-16 Jeff/Frank/Mike/Karl roadmap meeting

Mike Nolan's first meeting -- welcome, Mike!

Reference: Features Roadmap (Google Doc)

Notes:

• We'll set up the "LFC Evaluators" role in all competitions.

  A general question to ask about new roles is: which proposals can the role see? For now, we're going with "all the proposals that Board Members can see". Another possibility would be a superset of that, for example, including proposals that didn't pass peer-review.

• Next two deliverables are "Logging" and "Editability".

  Logging is mostly done. See demo notes a bit father down in these meeting notes.

  Proposal editability is in mid-development, and we'll show something as soon as we have it.

  (Both features are described further in the features roadmap doc.)

• Moved "Global View" feature onto the roadmap.

  After completion of the Logging and Editability features, the long-awaited Global View is up next. OTS will do some internal design work first, and then have a meeting with LFC to resolve design and UI questions that OTS can't figure out on its own.

  Note that researchers do not need the Global View feature to do their much-anticipated machine learning experiments. They can already loop over the (mere) 4 or so current competitions and use the API to grab all the proposals from each. So the experiments can start any time. There is no need to wait for Global View to be implemented, although Global View will simplify these kinds of large-scale data grabs once it's done.

• Three new competitions coming soon.

  • 2030Climate: We won't put the "2020" suffix on this one, to avoid causing the obvious confusion.

  • LSP: Lone Star Prize: Economic Development in Texas

  • ECW: (See ref:6d7efeb8 in internal notes.)

• Can we unify two different sets of climate proposals?

  MacFound already has a climate program. Now LFC will be helping to run a separate competition involving climate proposals. It would be nice to be able to view all those proposals together, but the two programs have different sets of fields (columns).

  Karl: Let's create a union set and run that through ETL.

  Frank: No, let's expose both field sets in the same competition wiki, because there's no rule that says every proposal in a competition has to use the same template. That way, all our ETL has to know is which template to use for which proposal. To make this work, there would be some generalization we'd need to do to the TorqueConfig:MainConfig page, but those improvements would help with other upcoming work anyway (e.g., global view).

  Karl: Frank is smart.

• LLIIA2020 status.

  • Geographic TOC is done

  • Topic TOC(s) are waiting for LFC to tell OTS what field(s) to use

  • Jeff polished up the left side panel, introductory text, etc.

  • Make sure to keep Muhsin in the loop for LLIIA2020 correspondence.

• Left-side panel standarization.

  For future competitons, we'll implement a standard base left-side panel which LFC may then customize further once the competition is up. We'll base this standard on the EO2020 competition. We'll probably defer this until we're also doing the ETL unification project, though, since a shared standard panel will obviously be easier to implement in a unified ETL system.

  Now filed as issue #72.

• Demonstration of in-progress logging feature.

  Demo'd here.

  OTS will make further formatting improvements, as Frank and Karl discussed in a follow-up call immediately after this meeting:

  • Trim down the "Logs" selection menu at the top of the control box.

  • Get rid of "Tag filter:" and "Show additional logs:" subsections in the control box.

  • After each log item's datestamp, put widespace-emdash-widespace.

  • All occurrences of (talk | contribs | block) after a username should go away

  • The word "User" before a username (in some MediaWiki-generated log entries) should go away.

  • However, note that entries that say "User account So-And-So was created by..." should keep the words "User account" on the front, although of course they should still lose the occurrences of (talk | contribs | block) as per earlier.

  • The (Created page with "...page content...") parentheticals should go away

• Handling proposal evaluation/review by third parties.

  The main thing is, put OTS in touch with the third party as early as possible, so we can tell them to send us the information in a spreadsheet, along with a sample of roughly how they'd like it visually formatted so we can set up the wiki page accordingly.

  (We'll probably want real a third-party review feature built into Torque at some point in the future, but for now we're still gathering data on what that feature would look like, so it's probably best for us to handle these manually for a bit longer.)

• When to change /lfc URL path to 100Change2020?

  Not yet. We'll wait until that competition becomes truly archival.

2020-07-13 Frank/Karl discussion about next things to do

• Frank to grab Better Logging from Mike

  Will create an issue in torque-sites. Events to log:

  • Viewing a page
  • Making a comment
  • Doing any kind of PickSome
  • SimpleFavorites action
  • API "dump all" request
  • Logged in for the first time
  • Logged in
  • Created a (non-proposal) page
  • Edited a (non-proposal) page
  • Deleted a (non-proposal) page
  • Renamed a (non-proposal) page
  • our bot refreshed all the proposal data
  • referer page (but only if within torque.leverforchange.org)

  Look into possibility of storing an arbitrary JSON blob as the log item text, and then specifying a callback for the rendering. This would allow us to change the output format retroactively in the future.

• Tech debt discussion

• Centralizing ETL pipeline Python code

  This will involve creating a shared library of ETL pipeline functions. This will still live in torque-sites, just in its own top-level subdirectory.

• Centralizing MediaWiki and SimpleSample to use distro packages

  ...and cleaning up how LocalSettings.php is configured. Long term benefits would include Jason's maintenance time, upgrades, new developer onboarding.

• +1 for Mike to script the setup process with current sample data

2020-07-09 10am CT Mike/Frank/Karl roadmap planning meeting

• Feature roadmap

  (Reference: LFC Torque Feature Requests and Roadmap)

  • Frank will take on "Adding the new LFC Evaluators role".

  • Mike will take on "Better logging".

  • Mike will take on "Editing proposal data".

• Mike will take on the left-side view dropdown menu issue(s).

  See issues #22 and #19.

• Frank to update LLIIA2020 to use the new-style standardized groups.

  (See also issue #64.)

• (DONE) Karl to propose Monday, Tue, or Thursday for meeting with LFC.

  Monday preferred.

• (DONE) Karl to re-encrypt all of LFC bigdata to include Mike

  See bigdata:r96 and torque-sites commit c9a5ddb684b.

• (DONE) Karl to request Okta accounts for Mike and himself In the "LFC Torque Admin" group.

  Keith in MacFound IT created these right away when asked.

• (DONE) Karl to document our design decision to use the distro/OS MediaWiki

  ...as opposed to some containerized thing. See issues #56 and #55.

• (DONE) Karl to give Mike a copy of the SOW.

• (DONE) Karl to grant Mike the necessary SVN path accesses

• See r16157 and r16159 in the internal repository. We discussed a couple of non-public items.

2020/07/01-2020/07/09 Frank/Mike various meetings in Zulip chat

Mike Nolan joined and started familiarizing himself with Torque and the competitions.

2020-06-17 12pm PT Jeff/Regina/Karl sync-up

• Complexities of "LFC Research Partner" role and permissions

  The ideal situation would be to have an administrative page that for a given role presents a checklist of fields, and LFC would just choose what fields that role can view.

  However, that feature would take some time to write, and it might not be the best prioritization right now. After some discussion, we decided that for the time being, these two roles will suffice

  1. LFC Research Partner

     Already set up. It's basically like Staff, except that it has no access to any rankings (neither wise-heads' nor judges' rankings), nor to financial attachments.

  2. LFC Evaluator (a.k.a. Technical Assistants)

     Similar to LFC Research Partner, but with no access to any judging data nor peer evaluation data. In other words: no rank (which is also true of LFC Research Partner), no total score, no criteria comments, no criteria scores, no access to financial attachments (which is also true of LFC Research Partner).

  During that discussion, eventually concluded that Prospective Donors (people who might want to dig deep into various competitions) are the same as LFC Research Partners, in terms of what they should be able to access.

  Karl will make a single page somewhere that says what the different roles see, and will link to it from the appropriate places. That new page should also link to the actual configuration pages.

  We discussed what constitutes sensitive data (see the 2020-05-30 meeting notes for a previous discussion about what is considered "sensitive data"):

  • Board comments (should always stay within board + LFC staff)
  • Rankings
  • Scores
  • Financials
  • Tech review comments
  • Pages that are specific to certain competitions (e.g., the Semfinalists page in EO)

• Upcoming competition(s) will be arriving soon

  Probably next week or maybe around July 1st.

  (See ref:22e246ea in OTS internal notes for details.)

• How to best incorporate third-party reviews (like, e.g., Bridgespan)

  Jeff points out that the central high-level question here is "How do we segregate proposals from diligence data?"

  Can we present a summary view of a competition to donors?

  Can we make a split-pane view possible, with proposal on the left and comment forms on the right?

  OTS to prototype the latter. Think of it as a structured version of TeamComments (it's really a superset of TeamComments, and so the latter might eventually get reimplemented using this new thing).

• High-level prioritiziation of features

  We need a place to see the current priorities list. Basically, we need a project management dashboard, or at least a running memo.

  OTS would prefer not to use Asana, for various reasons, so what we're going to do instead is create a "Torque Feature Requests" Google Doc. Karl will make that, bring it up to date (from the existing Feature Requests page), link to it from all the right places, and share it out. This will be our new project management place. (Later we might consider Etherpad, or a Rich Text editor in a wiki, but for now a Google Doc is a good most-of-the-way solution.)

  (UPDATE 2020-06-18: Karl has created the Google Doc and linked to it from the old Feature Requests page.)

  Current priority list:

  • Adding the new LFC Evaluator role

  • Better logging (for Cecilia among others)

    (Note: should show API accesses, e.g., by Candid.)

  • The cross-competition "global view" for LFC (see below)

• Global View

  Getting everything under one umbrella for LFC and research partners.

  We basically understand what this is, but we may need to define it a bit more concretely. It will be a major feature advancement.

• Report on what was fetched via API.

  Is there an easy way to know or check on what data was ultimately pulled via API by Candid? Specifically, main contact email addresses?

  Karl will see if we can just go into DB and get this information.

• Development forecast

  Karl pointed out that we're in a slow time right now, because we're hiring more people to do development, and that we will be making up for it once the new folks are on board.

2020-06-12 3:30pm Frank/Karl check-in

• LFCResearchPartner role may be getting more complex

  We could consider moving to a capabilities-based model. This would be awkward, though, because MediaWiki prefers a person to be a member of a group. Capabilities would come over as groups, and we'd have to know which groups are really groups and which are actually representing capabilities.

  We'll stick with the current way for now.

• Regression checks.

  We discussed the recent attachment-path bug. Karl to find a place for a new regression checklist to live. Some items for it:

  • If you've re-run the ETL pipeline, go view some proposals and make sure everything's still there.

  • Log in with various different permissions to view all the template you just adjusted. For each role, make sure all the data you expect to be there is there, and that data you expect not to be there is not there.

  • After a TOC change, view other TOCs and make sure they're still rendering correctly.

  • Check that attachments actually work.

2020-06-05 Frank/Karl discuss EO semifinalist data

There are basically two ways to create the wiki page that contains all thirteen Bridgespan analyses:

1. Torture the idea of a Table of Contents. But we agree we don't want this kind of kluge. We have taste.

2. Enhance Torque so that along with render tag, you can specify a view template. E.g., {{ #tdcrender:EO2020/id/460.mwiki }} would now take an additional argument specifying the template, and then there will be a single page that has some introductory material (including a certain table -- see below) followed by a list of all thirteen semifinalists, each using a #tdrender tags in this new style. This is obviously the way to go.

Okay, great, we're decided on (2) then. Here's how it will work:

There will actually be two new templates. One (call it "BridgespanTemplate") will render the information shown in each per-semifinalist Microsoft Word document from Bridgespan, though rendering it in wiki sectionized style not table style. The other (call it "BridgespanEntrySummaryTemplate" or something like that) essentially provides a mini TOC for each semifinalist, and we will use thirteen of them in a row to render the entries shown on Semifinalists_Supplemental_Materials. Note that the table currently at the top of that page will be moved to the new Bridgespan analysis page -- this is the "certain table" referred to in (2) above.

Frank will also rename the MwikiTemplate template pages to be named DefaultTemplate instead, so that we won't accidentally confuse them with the unrelated ".mwiki" extension that is used to request #tdcrender wiki output as opposed to JSON output.

Frank will record the specifics of all the above changes in an entry in the SVN-controlled file clients/lever-for-change/torque-sites/EO2020/maintenance/production-torque-updates.org.

Frank will update bigdata as discussed.

2020-06-01 Discuss CSV formatting with Mary of Bridgespan.

Mary happened to call Karl while Karl was on the phone with Frank, so we merged the calls and had a conversation about how to format the CSV files. Here's what we decided:

• Preserve all newlines.

• Use a solid "•" (Unicode 8226) for top-level bullet points, and use an empty dot "◦" (Unicode 9702) for second-level bullet points. Note that the current spreadsheet uses lower-case "o" instead of empty dot "◦". While we could convert "o" if necessary, it's certainly easier if we can just find a "◦" directly.

• When text immediately following a bullet point stops at a colon after a small number of words (say, 20), we will boldface the text leading up to the colon and the colon itself.

• Add two new columns to the overall spreadsheet: "Financial Overview", for the paragraphs in the Financial Overview that precede the table, and "Financial Overview Footnotes" for the footnotes that follow the table.

• The table itself will be in a file called N-financial-overview.csv, where N is the proposal's identifying number.

• For the financial overview table, OTS will make sure that dollar numbers and percent numbers in parentheses are colored red.

2020-05-30 1:30pm CT: Frank/Karl discussion about LFC Research Partner attachment filtering.

Frank will categorize attachments as follows, so that we can control who has access to which attachments. These categories may change in the future, but for now they're sufficient to handle the immediate access-control needs we have for the "LFC Research Partners" role.

• Sensitive to Applicant:

  • Financials

• Sensitive to LFC:

  • Tech Review (when non-anonymous)
  • Peer and Wise-Head Judging Comments (when non-anonymous)

• Agreements:

  • MOU

• Not Sensitive:

  • Tech Review (when anonymous)
  • Peer and Wise-Head Judging Comments (when anonymous)
  • Application
  • Covid Response
  • Fact Sheet

• Other:

  • (anything else goes here)

(Note: See also our later discussion in the 2020-06-17 meeting about what constitutes sensitive data.)

As per the 2020-05-14 meeting, attachments in the categories Sensitive to Applicant and Sensitive to LFC should not be visible to LFCResearchPartners. They do have access to the other specified attachments above, including Agreements, but for now they won't have access to stuff in the catch-all Other category (because we err on the side of conservatism until LFC tells us otherwise).

Note that we only have non-anonymous Tech Review comments, while conversely we only publish anonymized versions of the Peer And Wise-Head Judging Comments. Thus for the former, LFCResearchPartners won't have access to it, and for the latter they will.

Karl will follow up some more in the thread about the new data from Muhsin et al, among other things starting the larger conversation about how to bring in third-party reviews in a way that will be compatible with Torque.

Frank and Karl also discussed why we don't keep the wiki view templates in Git-based version control (Karl was wondering about this, when he was recently editing some templates). The reason is that others, e.g. LFC, sometimes edit those templates too. Also, whether others are editing the templates or not, they may want to view the templates' change history, so therefore that history is best kept in MediaWiki's built-in version control rather than in Git.

Karl blue-skied for a bit about how we could in theory have it both ways: version the pages in git, but the upload script would check to see if the production page had changed, and if so then display the diff and offer the various next-steps options, etc. But that's a lot of complexity for a rather minor process improvement. We agreed it's not worth it to implement that right now.

However, Frank pointed out that it would be very nice to have a command-line script that when handed a wiki URL would grab the page into your ${EDITOR} for editing, and then automagically push it back up to the wiki along with a log message when you're done. Karl said that the next time he's editing templates in the wiki, he'll implement that script.

2020-05-29: Jeff/Karl discuss access control, third-party reviews, etc

We agreed it was okay that LFCResearchPartners could -- maybe, in theory, if they were to have access to all proposals and know that they had access to all proposals -- rederive the rankings that are not directly shown to them. That is, the individual trait scores

Karl told Jeff that we're now working on the permissioning for attachments and that should be done soon. Big issue is the names of reviewers -- LFCResearchPartners should see only anonymized reviews.

Regarding Muhsin's mail, Karl will ask if they can put into a parseable form, e.g. Excel.

(Thanks to Jeff for taking notes and emailing them to Karl, when Karl had to call in to the meeting on his phone, from a park near The Medici, because power and cell phone service was out all around his neighborhood.)

2020-05-25 12pm CT: Frank/Karl discussion about logs and dev/staging sites.

• Regarding development / staging sites

  We should give macfound.opentechstrategies.com a new alias (torque-dev.opentechstrategies.com or something) and use that. Note that that's where the FeatureRequests page lives, so that needs to be preserved. But that's not really an obstacle to using that server for dev testing.

  Each deployment could use the "full deployment and ETL pipeline" method OR the "restore from latest backup" method. Using the latter at least sometimes would be good, for obvious reasons.

• Improving the Torque log page.

  (Note: This is now filed as issue #1 in the ActivityLog extension extension.)

  The way to cause more information to appear on the usual Special:Log page is to watch more hooks. For example, in a main.yml file, look at this block:

    - name: Enable ActivityLog
      blockinfile:
        path: "{{ mediawiki_install_directory }}/mediawiki-1.33.0/LocalSettings.php"
        marker: "## {mark} ANSIBLE ACTIVITYLOG CONFIG"
        block: |
          wfLoadExtension('ActivityLog');
          $wgActivityLogHooksToWatch["ArticleViewHeader"] = true;
          $wgActivityLogHooksToWatch["UserLoginComplete"] = true;
  

  Right now we're just setting booleans. We need to update the extension to take anonymous callbacks. Every MediaWiki hook has a set of arguments that get passed to that hook, e.g., "ViewPage" gets a user object and a page object. We would then pass those to the callback, and the callback would return a string that then gets inserted into MediaWiki's database for logged items, which then gets rendered to the Special:Log page.

  So instead of "= true" it'll be "= anonymous_callback_code_here".

  • We'll tolerate code duplication (in anonymous callbacks) for now.

    The above method means a lot of competitions will probably end up with the same anonymous callback code in their LocalSettings.php files. That's okay for now. We're still learning what things competitions want to differ on and what things they'll all be the same on. We don't know enough about their logging requirements yet, so let's not prematurely avoid duplication when we don't yet know exactly what the duplication will look like. (The proposed shared infrastructure would presumably have to go inside the ActivityLog extension somewhere.)

  • Contemplating different log access for different roles.

    Eventually, different roles should have different levels of log access. If we do that, then we really need to have a dedicated page for ActivityLog logs, which means that ActivityLog would need its own database (instead of just hooking into the existing MediaWiki logs database), etc. It's a rather larger task than just adding some anonymous callbacks to the right hooks, but it's still not huge.

  • Where to find out more about MediaWiki hooks.

    See https://www.mediawiki.org/wiki/Manual:Hooks (e.g., https://www.mediawiki.org/wiki/Manual:Hooks/ArticleViewHeader) for a list of available hooks. Warning: it's a long list, and the documentation is not always clear about which each one does. Experimentation is the norm.

2020-05-27: Pirin/Jeff/Karl discussion about CSV formatting and escaping.

We made some decisions about how escaping would work. The notes here are from the meeting itself and from a followup email conversation.

0. Character set and encoding.

   CSV files are in Unicode UTF-8.

1. Basic plan for escaping special characters.

   In the CSV, backslash will be used to escape newline, double-quote, and backslash itself, in the obvious ways:

       \n    \"   \\
   

   CSV-escaping happens after that, which means that each double-quote character will be doubled: "". Thus, if the user actually entered a double-quote, we'll receive \"", which we'll first convert to \" (because we un-CSV-escape it) and then to just " (because we un-backslash it).

   Current plan is for pipe to only be escaped (as \|) in columns where it would otherwise be treated as special (see discussion of budget tables below). However, followup discussion may lead us to always escape pipe, just to reduce the number of conditionals on both sides. We'll update this if that happens.

2. Handling lists.

   There will be a pipe (|) between the text blocks that represent the selected items from the list. This means that there will not be a pipe at the end of the final item, but that's okay because the CSV cell itself ends there.

   There will never be a CSV cell that contains both list items and free-form text entered by the user, so therefore we can know that, in a CSV cell that contains list items, the end of the CSV cell is also the end of the final selected list item.

   Obviously, if there is an actual | in a list item's text, it will be escaped with backslash (though in practice this is unlikely to ever happen).

3. Incoming CSV data is not HTML-escaped.

   Neither the header row nor data rows are HTML-escaped. Applicants cannot do HTML-formatting when entering their data -- in other words, if they enter the text "<br>", we will just treat that as a literal four-character string, no different from "fish" or "star". (If they had wanted an actual line break, they could have entered one or more newlines.)

4. Some list items come with prefixes pre-arranged.

   Some list items start with a prefix word like "Event: " or "Other: " and that's fine -- we don't need to do anything special, we just treat those like any other item. The viewer will understand what it represents (e.g., an "other" response that probably was offered at the end of a set of list items).

5. Handling budget tables.

   A budget table is a little bit like a mini-CSV inside a CSV cell. Here's how we'll represent it in that outer CSV cell:

   Items in the same budget table row are separated with a single pipe (|). The rows themselves are separated with double pipe (||).

   These are separators, not delimiters, so the list item in a row does not end with |, and the last row does not end with ||.

   We won't get a header row for the budget table (e.g., the "line item description" and "amount (us dollars)"), nor will we get the "Total" row at the bottom. We know the headers because we know what a budget table is, and we can (re)calculate the total if we want to.

2020-05-18 6pm CT: More Frank/Karl discussion about "Partner" view.

Karl will ask Keith in MacFound IT to set up a Partner role in Okta. Note that we strip spaces on our side: "Partner Researcher" would become "PartnerResearcher".

Regarding test accounts: You have to let MediaWiki know about the new group if you want to be able to assign it to local logins. The only way to do that is a line of code in LocalSettings.php, which implies that one really should do it via ansible.

2020-05-18 3pm CT: Frank/Karl discussion about new "Partner" view.

First, we confirmed that the anticipated URL change ("lfc" -> "100Change2020") has not happened yet.

Second, we discussed what's on the TorqueConfig:MainConfig page. Frank pointed out in Torque, "Template" always means a Jinja template. Then Frank explained what the current "Full" versus "Redacted" view templates really are, and based on that, Karl added a Notes column to the Templates table on the MainConfig page.

Frank had to hop off, but we'll talk later today. Agenda for that discussion is in the next entry.

2020-05-14: Jeff/Karl meeting sync-up and planning meeting.

• Add new intermediate access level, "Partner".

  Right now ,under the "View" option (drop-down menu in the left sidebar), there are two options: "Full" and "Redacted". We need to add another, resulting in three options total:

  • "Full" (same as current "Full")
  • "Partner" (new)
  • "Public" (same as current "Redacted")

  Partners get a collection of proposal summaries, displaying a limited set of proposals with a limited set of columns (this applies to both display and to printing out subsets of proposals).

  First we discussed some of the specifics of what "Partner" should have access. Jeff said they should have access to , but should hide these fields:

  - SHOW peer and wise-head judging comments
  
  - HIDE all comments from Board members
  
  - HIDE some attachments:
    + Financials
    + Tech Review 
  
  - SHOW other attachments:
    + Application
    + Covid Response
    + Fact Sheet
    + MOU
  

  In the Snapshot, for both Partners and Public, remove "Rank" and "Wise Head Panel Score".

  Partners can see all proposals, apparently.

  Then Jeff sent a spreadsheet with all the answers. (Frank: it has been committed as access-matrix.xlsx in r15838.)

• Making logging show what the person viewed or did.

  Note: This is now filed as issue #1 in the ActivityLog extension extension.

  In https://torque.leverforchange.org/lfc/index.php/Special:Log, show more information in each log line. Or maybe make a separate, better log page. (Hmm, wait, did we do that already? Check with Frank.)

  Question: who can view logs? Right now, everyone can. That's not good. It should be Admin, OR maybe the page looks different to different roles, OR maybe we just create a different logs page designed for our purposes -- similar to what we did with the "Recent Comments" page.

  See also ref:984e8492 in OTS internal notes for some additional though nonessential context.

• Upcoming imports / data coming from Common Pool.

  No problem here; we're ready.

• Improvements to printing

  • Include the Snaphot, or at least the parts of it that we want Right now the print TOC includes a "Snapshot" item, but no actual Snapshot data is present in the print version.
  • Get rid of "- lfc" suffix in upper left
  • Get rid of URL in upper right
  • Get rid of date/time stamp in lower right

• Logout button -- need one for users.

  But where would it take them? Front page of site? Does each wiki have a home page that's visible when one is not logged in? (Don't think so, currently at least.)

• Make sure that the role/template mapping system is documented for Jeff.

  Some competitions, like EO, have both Okta and non-Okta logins.

• Self-service file uploads [ref:c743a02e]

  LfC should be able to self-service when putting up new attachments.

  Can you update an existing uploaded file? And is the previous version saved as such, if so?

  What about uploading a brand new file?

  How to ensure something gets into the snapshot? (Answer is probably: just edit the template accordingly.)

  For now, Karl asked Jeff to hold off on trying to self-service-upload replacement attachments. Wants to talk to Frank and make sure that wouldn't blow anything up.

  See thread "Updating 7794 tech review attachment" from Jeff.

• The planned Corrections Interface.

• The Bat Cave View: a view-everything, cross-competition wiki just for LfC.

• Similarity matching comparison / listing (an open AI problem).

  To figure out how to group similar proposals, look at the "Lists and Collections" pages we have right now. That suggests Topic and Geography as two primary concerns.

  See also: https://xkcd.com/1425/

2020-04-17: Frank/Karl meeting re newline formatting etc.

Our ideas about improving wiki formatting by looking for patterns of consecutive newlines have foundered on the rocks of the inconsistency in the actual data. And using a regexp to match bullet points isn't so easy either, because it's not clear where the final point ends and the next paragraph begins. (See Frank's email ...)

"some poor intern whose job it was to copy and paste the data into the CSV"

Discovery that application PDF has most of the data.

100&Change 7322: arabic in PDF became ?? in CSV

Budget line items: xpdf->html more efficient than pdfminer (from cafr-parsing). Cache the files etc.

2020-04-07: Jeff/Frank/Karl sync-up

At Jeff's request Frank added the organization to the 100&Change 2020 TOC. He did this by just editing the template, and he told us how in Zulip.

Other than that, this was mostly a business planning meeting not a technical meeting.

2020-03-24: Frank/Karl sync-up

2017 MacFound competitions are now migrated to Torque. Partners site not yet migrated, but that should be easy now that MacFound's own site is done.

We don't know what usage of the 2017 site is like these days. Frank looked at the MediaWiki logs and discovered that some accounts were created in June of last year. Our guess is that when they were starting the 2020 project they went back and looked at 2017.

Frank will ensure that the newly-migrated site(s) are part of the regular backup rotation (see his message to Jason).

Frank will make sure that regular users (that is, regular wiki users in the newly-migrated 2017 site) can view proposal pages.

We renamed the old MacFound repository to torque-sites.

We are complete feature-wise: everything in the SOW is done. Now it's time to clean up tech debt. We have a standard way that things should work -- we just need to document that standard better, and update the existing sites to consistently use it.

DONE: Karl to ask Jeff about lfc/ to 100Change2020 rename and redirect. We won't do that until we get sign-off from Jeff.

DONE: Karl to let Jeff and Regina know that we're now entering regular maintenance mode.

Current tech debt stack:

• DONE: Code and system documentation everywhere, both in public code and OTS-private stuff.

• DONE: Documentation of APIs. There are two distinctions to be made here: overall, there's the internal API vs external API, and then for the external API, there's the general API vs the LFC-specific API.

  LFC-specific API documentation will live in the wiki itself, and the appropriate place(s) in torque-sites will refer to it.

• MAYBE DO OR MABE DEFER: We should use Debian packages for everything (MediaWiki, SimpleSaml, etc). Right now we're not. Solving this is a little bit hard: Debian puts MediaWiki in one systemwide place, so the way we deploy plugins would have to change. It's all doable, but would take some study. Jason and Frank will talk and decide whether this is urgent enough to do. Most likely we'll defer it until our next Torque contract, and then do it "just-in-time" style before starting on new sites. But Jason and Frank will talk and then come back with a recommendation.

• DEFERRED: Moving off MySQL to Postgres for 100Change2020.

• DEFERRED: DRYing out the torque-sites code. There is a lot of duplication within that repository, and we're not planning to clean it up right now. It's not urgent enough to do so; it's duplication but not especially problematic duplication. If we start hosting more Torque sites, especially for more organizations, then it would be worth de-duplicating that stuff.

• DEFERRED: There's no error-checking on sysop admin actions right now. If you're an admin (e.g., Frank, not Jeff), you can easily break the site and it will be hard to figure out why. We'll handle this opportunistically: see what errors we actually encounter and add checks for those.

• DEFERRED: We may have i18n / l10n problems in our code. MediaWiki itself is pretty fine in this regard; it's just our plugins that need work.

• DEFERRED: Torque currently stores the data spreadsheets directly in the filesystem, and we want to move it to the database (for security and consistency).

Frank will make a tech-debt label in the issue tracker, and file the above as issues with that label.

2020-03-19 Keith/Frank/Karl sorting out Okta authn and authz for EO.

(This was really two meetings: a Keith/Karl phone meeting followed by a Frank/Karl phone meeting.)

• Okta groups span an entire Okta organization.

  That is, the groups available to MacFound/LfC are the same across all the apps ("chiclets") within that organization. The same groups are always mapped to the same user: when a MacFound/LfC user logs in via Okta, no matter via which app, that user gets all of their Okta groups every time. A user can, of course, be in multiple Okta groups.

• On the Torque side, we can map Okta groups to MediaWiki groups.

  This mapping can happen on a per-competition (per-wiki) basis. So a user can have different MediaWiki groups in different competitions.

So for example, Okta group "EO Donor" might map to MW group "DecisionMaker" (see the 2020-03-17 meeting notes for the default list of Torque/MW groups).

Keith created the "LFC Staff" Okta group and put EO users in it. We now need to map that to the "Staff" MW group.

Frank will make it so that the Torque configuration page that controls authz will start using our new MediaWiki groups.
More context in Zulip.

2020-03-17 Frank/Karl discussion re EO and user/group permissions.

• In the long run, enabling Okta for EO is the right move.

  Keith sounds ready to do that right now. DONE: Karl will check with him and Jeff. See Zulip for the required configuration.

  Frank notes that adding a new Okta app is about 30 minutes of work, but coordinated between two people, one on MacFound IT side and one on OTS side. So in practice, it's going to be more than 30 min in wall-clock time.

• Open research about sharing Okta apps across multiple sites.

  Frank wanted to see if we could enable Okta on both sites without MacFound IT doing anything differently -- IOW, using the Okta app. Frank has not had a chance to do that research yet though. He is about to, though.

• Different permission sets for different competitions.

  Probably LfC would want a different permission set for each instance anyway. There may not be an exact equivalent of a BoardMember for each instance, and even if there were, the set of people who are BoardMembers may differ from instance to instance: someone who's a BoardMember on one competition might be have an advisory role in another.

• Generalizing our user group classes.

  In general, what are our user classes? Let's start from LfC's groups as a guideline. We have:

  • TorqueAPI (Candid API)
  • ForumOne (ForumOne API)
  • LFCConsultant (e.g., an outside reviewer)
  • PseudoBoardMember (staff member masquerading as board for testing)
  • BoardMember
  • Sysop (MediaWiki-based administrator group)
  • LFCTorque (LfC staff member without administrative privileges)
  • LFCTorqueAdmin (LfC staff member with administrative privileges; basically a synonym of Sysop)
  • Robot (bot accounts like csv2wiki)

  Generalizing that, we might use the following as default Torque groups (maybe we'll retroactively fix MacFound/LfC to use these):

  • OutsideReviewer
  • Staff
  • PseudoDecisionMaker (for staff to test DecisionMaker interface)
  • DecisionMaker
  • Administrator
  • Robot

  (See torque-sites issue #62 for more on this.)

• What the EO experience should be.

  The login page would have two buttons as choices:

    [ Log in with Okta ]
  
    [ Log in here with username/password ]
  

  When you're logged in via Okta, you stay that way (until the cookie expires), and visiting any page in the authorized site is a seamless experience -- you do not get needlessly confronted with a login page.

  If you're an Okta-enabled user going to a specific proposal page but you do (for whatever reason) need to re-log-in, then Okta and MediaWiki will cooperate to redirect you to the desired end page once you've completed the Okta login dance again.

  What about local login?

  Torque in general will need to support local login, in the long run. We need to go over all the available user rights in MediaWiki and define our groups ("OutsideReviewer" etc, as per the list given earlier) in terms of those. Our new groups will be defined in PHP: this is default configuration that Torque will ship with out of the box.

  We may or may not need local login for EO right now.

  (DONE: When asking about Okta, Karl will also check with Jeff whether local login is actually needed at all for EO now.)

• Extended discussion about Read vs SubmitChanges vs Write permission.

  Under the hood, we have three kinds of data:

  • MediaWiki data
  • Torque data
  • side data (like PickSome, TeamComments, etc)

  Re read/write permissions for MediaWiki pages: we can hide the "Edit" button, but truly protecting even from API calls is annoying and hard. It will save a lot of hassle to just say that stuff that lives on the wiki itself can never be locked down from a write point of view, although Torque data of course can (and has been).

  Take the Lists And Collections pages that Jeff creates, for example: to lock those down so that only authorized users/groups can do what they're allowed to do would be very hard. The MediaWiki API is finite but very large. And then every time we update MediaWiki we'll have to see what's new in the API and make sure our lockdown changes get extended to that new stuff. So either we need to build in this ongoing extra cost into any SOW, or we need to make sure everyone has a clear distinction between "data that lives in Torque" and "data that lives in the wiki" and knows that we can only really protect the former.

  Or take this scenario: Candid staff uses API to get data from Torque-based proposal pages and generate a new wiki-based page, and wants the new page to have the same access perms for the same people as all the proposal data from which it was derived (assume for the sake of argument that that set of proposals is entirely in an internally consistent access group). How can Candid's staff ensure that the new page is safely permissioned in the same sense that the original data is? Right now, they can't, and Frank says this is impossible to do without hacking on the MediaWiki API layer, which would be brittle in the face of upgrades of course.

  Bottom line is: we're accumulating some design/tech debt because of our dependency on MediaWiki. Future SOWs need to take this into account.

2020-03-13 Frank/Jeff discussion about EO

The purposes was to go over the newly deployed EO site, and fix any quick items and add todo's.

• Update the main site with wiki text describing the competition
  • Jeff did this
• Add logo for competition to site. This was done quick and dirty and needs to be added to the ansible setup (after site is live)
• Add teamcomments to site
• Add SimpleFavorites to site
• Add a listing of all Proposals (and update side bar)
• Fix population having young adults twice

Otherwise things look good for the first pass.

Also some time was spent on looking at RSS on the main LFC site, and a todo item was added to make a given rss xml work. Similarly, investigate maybe adding a twitter hashtag watching extension.

2020-03-13: Frank/Karl check-in

EO stuff up on or before Tuesday. MediaWiki-local login for now; Frank has created an Admin user and will put it in encrypted vault.

How will we let an API user (e.g., Candid) know that some data has been updated? Well, short answer is: whenever we refresh the data (e.g., because we've gotten an updated spreadsheet), we rebuild the Whoosh search indexes. We could easily add an API for "last updated date". It would be at a whole-spreadsheet granularity, not per-row (let alone per-cell), but that's probably enough for Candid or anyone else to flush their cache and refetch as needed.

Now, suppose LfC changes permissions such that a particular column becomes newly available to a certain API user. In effect, even though the spreadsheet wasn't updated, that API user still needs to update any local caches they're keeping. Fortunately, piggybacking on the Whoosh search indexes works out well in this case, because we're already keeping a separate Whoosh search index for each of permission group anyway.

In other words, if we just remember the date of each Whoosh search index rebuild, and make that date available via the API to users whose permission set matches that search index, then that works. We just need to be careful that this dependency between search indexes and the up-to-dateness API is not implemented fragilely: if we later change how we do search indexes, the API still needs to work.

Frank points out that the HTTP Last-Modified header might be the right way to carry the information, though we didn't decide on that for sure.

If some day we offer an API for gives per-row or even per-cell "last update date", then all of this gets more complex of course.

Karl asked Jeff whether Candid needs the cache update ability given that there's no corrections UI yet anyway, in this email:

  From: Karl Fogel
  To: Jeff Ubois
  CC: Frank Duncan
  Subject: How can Candid find out when data has been updated.
  Date: Mon, 16 Mar 2020 16:06:10 -0500
  Message-ID: <[email protected]>

2020-03-09: Jeff/Frank/Karl

• Documenting the extra stuff

  Karl to assemble for Jeff a list of everything we've done that wasn't originally in contract. C.f., memo from a few months ago about iterative development.

• EO challenge: the data is about to come in

  Basically, we're ready. Bring it on.

  Re EO authentication: Local login is fine for now. If MacFound IT wants to use Okta for EO, then they'll need to set up a separate Okta app. Karl explained the dual-method route vs Okta-only route. Jeff may have MacFound IT set up a new Okta app for this, since that will probably be needed either way.

• Consolidating information

  Have an all-comments view.

  Should we have a non-proposal page for global (non-proposal-specific) comments? Maybe. Discussed, but did not decide to do it yet.

• Voting process

  LfC will just use an Excel spreadsheet -- this is an 80% solution, but it's the most direct way and requires no new technology.

• A corrections interface

  A vs B: Either we go down this path, or periodically they send us corrections. Option A is an enhancement to all future competitions.

  Frank and Karl to estimate it, then follow up to Jeff. DONE: Karl later sent estimate to Jeff:

    From: Karl Fogel
    To: Jeff Ubois
    Subject: Estimate for implementing a corrections mechanism.
    Date: Wed, 11 Mar 2020 17:48:54 -0500
    Message-ID: <[email protected]>
  

2020-03-05 Frank/Jason discussion about multi competition

The purpose of this meeting was to decide how to handle multiple competitions in the OTS world. The following questions were answered after we got up to speed about the requirements and details.

The toplevel overview is the following

• ETL/Competition config lives in github/OTS/MacFound/<Competition>/{etl,ansible}
• competition opass lives in clients/lever-for-change/torque-sites/<competition>/ (see below for details)
• machine opass lives in clients/lever-for-change/<machine>
• server logs live in svn:clients/lever-for-change/<env>/server-updates.log
• confidential competition data lives, encrypted, in bigdata-svn:clients/lever-for-change/<competition>/

(Karl says +1 to the general idea above, but notes that specific paths may, in the medium-to-long-term, be different from what's above.)

(Karl adds that on 2020-05-18 he retroactively adjusted some paths in this entry, above and below, to reflect the post-r15840 universe.)

Moving to debian mediawiki package?

We should do this, but it will require extensions to be shared across all competions, and then enabled per competition in their own LocalSettings file.

May have to update backups to include these deployed files to make sure we can restore. Maybe do some fancy simlinking to the ~deploy directory.

Where do ansible roles live?

Decentralize the roles into each repo they live in. For instance, the ansible role for the PickSome extension should live in the new OpenTechStrategies/PickSome repository. Then figure out how to add the github repositories dynamically to the ansible galaxy when deploying.

Also, for example, create a tiny repo for the ansible work done to deploy mwlib (the external book printing library)

Note: While there will be a base mediawiki install role, each competition will likely get its own role that has the configuration specific to that competition if the configuration is sufficiently diverged enough from what can be easily expressed in configuration files.

Where do ansible playbooks live?

In github/OpenTechStrategies/MacFound (probably to be renamed). In that, there will be subdirectories per playbook, with each one having a "ansible/deploy.yml" Any competition specific ansible roles will live there as well.

Note: The ETL pipelines will live in MacFound/<competition>/etl

Where do ansible variables, including secrets live in opass?

Non secret variables live with ETL pipline. These are usually OTS specific, but then, so is the whole ETL pipeline. This includes things like installation directory, deployment user, etc.

Secret variables live in the OTS svn repository, in opass. These specifically live in:

/clients/lever-for-change/torque-sites/<competition>/ansible/<env>

There's also information for competitions like mediawiki logins that live in

/clients/lever-for-change/torque-sites/<competition>/accounts

And then information for the machine that doesn't have anything to do with the competitions:

/clients/lever-for-change/<machine>

Where do ansible hosts files live?

In ETL pipeline. Since each competition gets its own playbook with what roles it uses, the hosts need to live in conjunction with that playbook. This can have OTS specific machine information in it. Need to look into how to centralize the cross competition information.

Do we reuse credentials for each competition for the base OTS mediawiki accounts (there are roughly five)?

No! New credentials for all. Manage with scripts. This includes database connection login/password

Does torque connect to that database server with the same credentials?

Per torque instance. This requires torque to actually use a database.

Where do server logs live?

In subversion:

• /clients/lever-for-change/<env>/server-updates.log
• /clients/lever-for-change/dev/server.log - tells you to look in the other place

Where do OTS specific scripts live?

These are helper scripts that call out to opass to generate inventories files for competitions with all the secrets put in right places. They live in GitHub, in torque-sites.

Do we need a one-stop all.yml playbook that freshly deploys all competition playbooks?

Nope, because the backups world should take of redeployment

2020-03-03 Frank/Karl discussion about security and design

We actually had two meetings, one at 11am CT and another at 5pm CT. In between them, Karl had a conversation with Jeff about upcoming requirements and competitions.

Regarding security:

Read permission is hard to lock down within a wiki. There's not even a native way to read-lock a wiki namespace. The LockDown extension tries to solve some of these problems, but it keeps getting the rug jerked out from under it by MediaWiki core updates. The render-page hook is not an answer, either: not everything is a render, and anyway that hook just returns True or False, and how that gets handled in a particular context is up to MediaWiki not us.

Viewing logs, for example, creates authz problems. You'd have to do API lockdown to authorized proposals -- really putting some guards around the usual MediaWiki API. It really comes down to silo'ing wiki users: that's hard, especially in a multi-competition world.

If we were going to share multiple competitions within the same wiki, it would involve some work and some rules:

• No creating pages in the default namespace

• Strict rules about creation in other namespaces (e.g., you'd get 500 errors if MediaWiki changed something incompatibly, rather than a security hole)

• Go through all the non-default namespaces MediaWiki ships with and decide exactly what permission each group of users has w.r.t. that namespace

• mwlib would be a superuser read-bot account

• LFCTorqueAdmin and our bot accounts would retain godlike powers

Another answer is to just have a separate instance per competition. This shifts the overhead to configuration, deployment, and maintenance issues, but on the other hand it solves a lot of the security issues.

Note that LfC did say, when we were originally discussing these issues, that it's okay for anyone who can log in to the wiki to be able to see anything in there. The same is not true for API users, of course. And anyway we've ended up applying similar access control granularity and standards to the wiki as to the API, even though that's a bit farther than the SOW required.

Anyway, after the conversation with Jeff, we (Frank and Karl) decided to go the latter route: one wiki per competition instance.

Some random notes:

Going to a specific competition URL redirects you to a specific Okta app (an "app" is sort of like "domain" or "instance" in the Okta world). After sign-in, that app redirects you back to some predetermined URL (which may or may not happen to be the same as the original URL). It has to work this way, obviously: for security reasons, the user signing in cannot specify the URL to return the authenticated credentials to.

Lock down the MediaWiki API to prevent write operations (e.g., deletion of pages).

There are some design and code ownership issues with the one-wiki-per-competition decision. Creating a new Torque instance involves these ansible roles, which have all sorts of LfC- or OTS-specific stuff: 5 ansible instances.

Frank will first put "/100Change2017" on the dev site (wiki.opentechstrategies.com) then "/100Change2020" (the latter with data copied from production). Question from Karl: my actual notes said those two would share a wiki (presumably because their two competitions within the same organization). But I think that reflected our old, pre-Jeff-conversation understanding, and that what we really decided was that each of those two competitions would still get their own wiki, and that our plan really is one wiki per competition, period, at least for now. Karl will check with Frank and update this paragraph.

Karl will put the 100Change2017 data into the bigdata area. Karl told Frank that we don't necessarily have the 2017 attachments zipfile anymore, so that those might have to come from the production instance (on macfound.opentechstrategies.com) or from a backup thereof.

2020-03-02 Frank/Karl high-level status and issues check

Notes from this meeting have been folded in to the 2020-03-03 meeting above, in order to organize the material better. It was essentially one meeting spread out over two days.

2020-02-27 Frank/Jason/Karl UI discussion

In the left side bar, change the "Torque" section to just "View" and change the two available view names to "Full" and "Redacted", defaulting to "Full" (formerly "Web").

We discussed various other things and explored the templates, but the above is the main consequential outcome from this meeting.

2020-02-25 Frank/Karl discussion of search considerations

MediaWiki search is not modular in quite the way we want. The MW results are a package (the repeated search bar, content type bar, create-new-page offer link, and then the actual MW search results) and all of that package comes first. Then after it come the Torque results, which are implemented as a search append hook.

(Note that we're not using the pre-search hook list method, by the way. That's the list of external hooks that MW runs first. Each hook gets the search string and an output stream, and any hook can use that search string to do whatever it wants -- presumably look it up in some search index -- and write results to the output stream, and once any hook returns False, processing stops and MW's own results never even get displayed. But, again, we're not using that; we're using the append hook, which is different.)

DECISION:

For now, turn off the entire MediaWiki search results entirely. Just offer the Torque results, which for now will just include results in live proposal pages. We could at some point extend Torque to search within MediaWiki, though that would require some contortions (Whoosh indexing changes, etc), but let's not worry about for now. It's not so to get results in non-proposal MW pages right now -- the proposal pages are far more important and are what the Board needs as the highest priority.

There is no limit on search results -- no pagination. Later on when someone hosts a competition with 10,000 proposals, sure, then we can implement pagination. One thing a time.

2020-02-21 Jeff/Frank/Karl discussion re templates and competitions

• Template design

  DISCUSSION:

  Jeff said that they need to be able to adjust the templates b/c they're going to be dealing with idiosyncratic needs. There are lots of requests for "I'm going to this meeting about health care, so show me all the proposals about health care". Thus book printing is just one case of handling custom requests for information. If they'd be sharing the book publicly, for example, they know they don't want judges' comments to shown.

  DECISION:

  Templates will be their own thing (which was the way we'd been leaning anyway). Templates will be in their own section on the admin page, i.e., there will not be a default template associated with each authentication group anymore. There will just be an arbitrary number of named templates that the Torque admin(s) create based on their instance's specific needs. Field-level access control happens within each template, using per-field conditionals chosen by the template author.

  The available templates will be listed in a section in the left nav column. A logged-in user can choose which template they're viewing things with. You might switch to a particular template for book-printing, or for giving a public presentation, for example. If you don't want to show (say) judges' comments, then you use a template that doesn't include those comments.

  When a user chooses a template, that choice persists according to the Principle Of Least Surprise: for example, if someone is giving a public presentation, and they log out and log back in (accidentally or intentionally), then the template they were using in the previous session should still be active. There is some careful thinking to do here about associating template choice with session cookie vs associating template choice with the user in some kind of internal database record that remembers the "most recently chosen template" in case no overriding cookie indicator is found. We need to sort out the details of this, and our guiding concerns in doing so will be security and the Principle Of Least Surprise.

  (Also, an idea: We didn't discuss this in the meeting, but there's a possibility for users eventually to be able to define their own templates, without involving an admin. We won't be implementing that right now. I'm just noting it here so I can look prescient later.)

  Btw, Frank confirmed that JSON API output is not done via a template. We just return the authz-permitted fields in a straightforward dictionary-style JSON document.

• Multiple competitions: do we use multiple instances of Torque?

  DISCUSSION:

  Each competition is likely to have some tweaks to the templates. Jeff says that nobody but Jeff cares about having one giant wiki to rule them all.

  DECISION:

  In general, we'll decide an ad hoc basis whether or not to set up a new Torque instance for a new competition or for a new organization that may have multiple competitions. It depends a lot on authentication/authorization/administration needs, and on how advantageous it might be to have unified logging.

  However, within a given instance (e.g., the LfC) instance, we will start using Mediawiki namespaces to keep competitions separate from each other. We're not doing that right now, and when we introduce it it may have some URL implications, so we'll need to think through the transition, but we're pretty sure it's an overall win and that it will make hosting multiple competitions in the same Torque instance easier.

• Immediate priorities

  What we expected: Finish search feature, then do logging feature.

• Medium-term priorities

  • Next feature coming up: extension for Board Members to distribute 10 points each across the ten finalist proposals. We will probably generalize the PickSome extension to be able to do this too, rather than write a whole new extension.

  • Soon we'll discuss preparing for the next competition. We're not sure who it will be yet. Jeff will keep us in the loop.

Frank and Karl had some internal followup discussion about search design after Jeff had to leave for his next meeting.

• Search on all authz-permitted columns, independently of template.

  This has the interesting implication that a search on "foo" might return result pages where "foo" is not visible in the page (because the current template does not include the column(s) where "foo" appears and those columns are responsible for the match.

  We think that in practice that this will not lead to confusing search results, because most of the time people are searching on words or phrases that they've seen in a page (e.g., "health care"). Varying search results by template would be too weird; what if you do a search and then switch templates while viewing the result set -- should the membership of the result set change? Heck no.

  This means that under the hood Frank will be having Whoosh essentially do foreach loop over each column.

• Memory usage and search indexes

  We may just build one search index per authz group, because that's the easiest way to get the right behaviors. This will not be a memory problem with current data sets. If it ever becomes a memory problem, there are some obvious optimizations to make. One of them is so easy that Frank might do it on the first pass: groups that have the exact same permission sets can share an index.

2020-02-20 Frank/Karl Meeting about search functionality.

Current state: vast brokenness, not useful.

First-pass solution: just clear away the current brokenness and get simple case-insensitive word-based searching working, probably using Whoosh. We'll discuss fancier search capabilities later; for now, top priority is to make search behave in a reasonable and expected way for users who are doing basic searches. Communicated plan to Jeff in Zulip.

Frank later remarked "Actually, looking at this, I think I'm just going to do the indexing thing I was talking about on phone. One index for each group. Looks like it's super straightforward ... to just create whoosh indexes per group."

2020-02-03 Laia/Jeff/Frank/Karl discussion about API issues.

• Fields missing from API that Candid would like to have.

  We know there can be up to 5 current locations and 5 future locations, but the API only shows 1 of each. It should show all of each (all ten, in total). We will make all of those columns available.

• Displaying rank.

  In SolutionsBank, Candid wants to designate them as "honorees", "finalists", and "awardees", so they need to know which proposals are in which categories. This information will be present (in the appropriate column(s)) and the API will be able to offer it, we all agree, and we further agree that we don't have it yet :-).

• How many proposals to show in SolutionsBank?

  478 is the number that made it through admin review process.

  456 is the number that made it through peer review process.

  Frank will narrow the filter so that just the 456 are visible to Candid via the API.

• EIN issue resolved.

  Candid says it looks like they're getting the Org ID type, but not the actual ID? Frank and Laia got this straightened out. Karl didn't catch what the solution actually was, but he has full confidence in everyone else on the call. Ahem.

• Frank noted to Jeff that some of the corrections involved title changes. Explained placeholder workaround and future solution involving mediawiki redirects.

• Andrew's using the API via Mediawiki PHP SDK, just FYI.

2020-01-09 Frank/Karl discussion about API and cleaned-up spreadsheet.

• Laia Grino's mail and how we should process the spreadsheet she sent.

• API discussion

2020-01-02 Frank/Karl check-in

• Delivering torquedata api on January 13th for v1

• Set up authentication to come from mediawiki so macfound (mainly Jeff) can edit

  • Need to set up authentication about who can view that page
  • Will be two part: one part of the scheme will be in torquedata, where permissions sets can be set up. another part will be in mediawiki, which assigns mediawiki group, or user, to a permission set.

• Authentication system for api to use just htpasswd and htaccess for right now

• Candid will get us a updated cleaned spreadsheet (Karl to follow up)

• Going to do full template system in mediawiki for v1. Will update mediawiki to use this system soon after

• Frank to bluesky all outstanding issues that were on his plate

  • Comment feed
  • Personal comments
  • Comments special page
  • Related proposals

• Karl to follow up on Bruce accessibility analsysis

2019-12-23 Frank call with Solutions Bank

• Some fields will need to be formalized

  We need to have fields be useable beyond just strings, and so they will need to be fixed in case there are deviations. Who is going to do this? (Answer: Candid will be doing this by providing us a fixed up spreadsheet)

• We'll be using json

• Accessible on the open web. Authentication is currently an open question, options include

  • IP address (hard pass from Karl)
  • Okta where we authenticate
  • Okta where they authenticate and pass us token
  • Internal database

• There are no requirements related to the test data

• Full set or restricted set (Karl says full set)

2019-12-12 Frank/Karl check-in.

• Implementing Wild Card freezing.

  Confirmed how we'll implement Wild Card freezing: the authz callback will take a new action parameter (value would be, e.g., "add" or "remove"). That way we can implement various kinds of freezes, and authorize future actions that go beyond addition or removal. The freeze we're implementing here will just return Boolean false for both of the current action types, of course.

  Frank is working on this now as his next priority; it will be ready for Monday and he will turn on the freeze early Monday morning.

• Make sure LFC Torque Admin can still add/remove Wild Cards.

  This is in anticipation of LfC's need to possibly change Wild Cards, at the Board's request, after the official Wild Card selection period is over and Wild Cards are frozen.

  Karl to tell Jeff about this.

• Showing Wild Card and Comments activity.

  Frank pointed out that the usual Recent Changes pages is a security hole, since everyone can see those. Instead, we'll have PickSome and TeamComments emit custom events, and have an LfC-specific configuration that watches for and logs those events to a special database, and have a single authz-controlled page where an LfC Torque Admin (Jeff, Regina, et al) can view the record.

  Frank will capture this design in a new issue, and put the blue sky label on it.

• Confirmed that first-time logins are shown on the ListUsers page.

  Frank confirmed that the "Created on" language on Special Pages -> User List means what Jeff correctly speculated it means: when a user logs in for the first time through pluggable-authn, Mediawiki it creates a new entry in the users table, and that's the event shown here.

  Karl to tell Jeff this is confirmed.

• Comments feed: talk to LfC about whether we should do it.

  Frank points out there has so far been one comment left in the entire wiki. Given that, is it worth implementing this?

  Karl to ask Jeff how much they still want this feature.

  Frank and Karl agreed that if we implement this, the presentation of the feed would just be a list of proposal pages (just the title, as a link to the proposal page), and under each item in that list would be all the comments associated with that proposal. The lOrdering of the top-level list would be by most recently left comment, and the most recently commented-on proposal page would be first (that is, reverse chronological for the top level, though comments themselves would be shown in regular chronological order of course).

• Karl will follow up with Laia et al about next week's meeting.

  Tuesday and Thursday are best for OTS.

• Do we receive normalized geographic information?

  Karl to check with Jeff, Laia and Gordon:

  For Geo stuff, will we (OTS) get pre-normalized / pre-vetted stuff that already matches GeoNames (e.g., either a name that's a perfect string match for a known GeoName, or perhaps even just a GeoName numeric ID), or are we going to have to normalize fuzzy input data?

2019-12-11 Jeff/Karl sync-up after Candid call

Don't shut off Board access on Monday, just freeze Wild Card selection. Karl to tell Frank. If LfC is going to change its mind on this, they will notify OTS before Friday.

See also the 2019-12-09 entry for some inline notes where questions raised then got answered today -- search for "2019-12-11" there.

2019-12-11 Candid / LfC / OTS roadmap planning call.

With Laia Griñó, Gordon Green, Jeff Ubois, Karl Fogel.

Original agenda, for reference:

• Are we correct to go with country, state, district level coding worldwise?

• Is there a service, such as Geonames, we should reference, or are we better off working with CSV files and lists?

• Is there a single set of numeric country codes we should reference?

• Are there recommended designs for gathering geographic information?

• Is Geonames the best way to synch the data we gather with other Candid databases?

• What might a path to a working system look like, if we are starting now with a csv file?

• How will our choices affect the experience of applicants, and the experiences of people looking to compile lists of projects based on their location?

• How do we handle ad hoc categorizations, such as regions, or "places" that are in the gazetteer such as "space?"

Jeff: Incoming data is not ideal because intake UI may not be asking the right questions re geolocation data. Tension between using existing standards vs having everything "just right for us".

Gordon: We use GeoNames primarily and they have a pretty good set of APIs. But GeoNames has some limitations and we have mechanisms for dealing with that: we have internal identifiers that match up to GeoNames for basic stuff (cities, countries, etc). But there are entities (e.g., census names) that don't exist in GeoNames -- we use our own internal identifiers for that. And then there are some things that exist in GeoNames but that we have different definitions for, like "Europe". However, our direction is to move more toward GeoNames's standards. GeoName does have a lot of stuff: regions, zip codes, congressional districts (we believe), etc. Laia says it's increasingly difficult to maintain one's own standard -- better to move to GeoNames.

Ultimately we decided on the following for LfC data:

• USA: Country + Admin1 + Admin2
• Rest of the world: Country + Admin1

Gordon sent these GeoNames links:

• https://www.geonames.org/export/geonames-search.html
• https://www.geonames.org/export/place-hierarchy.html#hierarchy

Then we talked about APIs in general, and we agreed to have a tech team conversation next week to make sure OTS implements what Candid needs.

2019-12-09 Frank/Karl check-in.

• For API, include all data and all applications (even incomplete ones)

• Jeff asked about consolidated feed of all comments.

  Reqs exploration needed: what is this really for? Let's outline the problem definition first and then see if this is the right solution. It's not technically hard to do -- all the information is in a database -- but we should grok out what's actually needed here.

  Karl later (2019-12-11) followed up with Jeff and got this answer:

  Yes, any Board Member or LfC Torque Admin staff member (i.e., super-powered staff member) can see the feed, and it should be a Special Page, like "recent changes" but its own separate page (don't mix it into Recent Changes).

• Viewing login stats

  Jeff said re "Board members group — is it set up": "No complaints, but I don't see it as I do lfc torque and lfc torque admin." Frank responded "Incidentally, this statistics page is fixed now because I'm doing a bit more preloading of permissions in LocalSettings meaning that MediaWiki knows about valid groups."

  If LfC's need was to find out which Board Members have used the system at all, then yes, this need is now met. If it was deeper than that, like a need to know what activities they've engaged in, then we need to talk about it.

  Karl later (2019-12-11) followed up with Jeff and got more specific:

  Is Mediawiki collecting what we want on Special Pages -> User List?

  Karl to check with Frank: are we sure this list lists everyone who has logged in? (Meanwhile, Jeff is checking with Keith and Chris whether they can get that information from the Okta side.)

  Also, can we make sure that choosing Wild Cards or making comments is counted as activity by MediaWiki?

• Regina's request that "No Wild Card Pseudo Board Members" group be on roadmap

  (See thread "VoiceCloud Message From: ...")

  Karl filed blue-sky ticket #15 for this on 2019-12-11.

• Notes feature?

  We don't have it right now; could go on roadmap. It's trivial to code, but non-trivial to design the right UX. And it might be that there is not really a better solution than people just keeping a file of their own notes on their own computer.

  (See thread "Re: Fwd: Wild Card system access = immediate questions")

  Karl filed blue-sky ticket #16 for this on 2019-12-11.

• Top 200 output with wisehead info

  Jeff says: One complete table with everything would be useful. There will be other applications where judge data is not wanted or needed, but I can delete columns as needed.

  Frank said "There's some requirements gathering here, but I can just dump out my best guess and move on.  (requirements gathering is for things like "what should the column header name be for P2P review Impactful comments), etc.

  (see thread "Top 200 output")

  DECISION: Jeff says this is on hold / nice-to-have. Don't do it right now, but it might be nice to have later, and LfC will let OTS know if so.

• Agenda for upcoming LfC/OTS check-in

  • API-based access to clean data

    Action item here is talk to Laia's tech team at Candid next week and understand what they will need from an API.

  • Geocoding, subregions, etc

    No action item here right now.

    Some possible future uses of geographic information:

    • Identify donors interested in a geo area
    • Assign proposals based on interest/expertise in a geo area
    • Region-level interest (e.g., Asian Philanthropy Network)

  • Quickly setting up custom wikis for other donors

    Didn't get to discuss this in the 2019-12-11 followup meeting with Jeff, but we now it's coming and we're ready to do it.

  • Tech review going down an email-based path

    Decision: That's okay. This was discussed internally already. Getting the tech reviewers into the wiki, with Okta integration, would be too complex. The tech review process is very ad hoc. We will just upload the tech reviewer's reviews as attachments (probably Word documents) to corresponding wiki pages. The files will have easy-to-parse names like 8076_TR.pdf.

  • Frank was going to close all Board access early on the morning of Monday Dec. 16th (close their Okta-enabled logins). In the 2019-12-11 followup call, Jeff said don't do that, just freeze Wild Cards. Karl will let Frank know.

2019-11-25 Frank/Karl sync-up meeting during Wild Card Selection period.

• Local login for sysops is done. Account creds are in the usual place.

• Making generated pages read-only for everyone except the LFC Torque Admin group and MediaWiki sysops (i.e., those who log in via the special local URL with password) is done and tested on staging. Frank will deploy tomorrow morning.

• Wild Card Selections are no longer visible to staff in the LFC Torque group.

• Frank will coordinate with Bruce on accessibility testing and to give Bruce feedback on his draft report. Will offer to phone.

• Karl will check in with Regina to make sure everything's going well with the Board's use of the system.

• These data files will go into the MacFound repository:

  • Subregions declaration spreadsheet (what countries go in what regions),
  • SDG numbering spreadsheet
  • Populations spreadsheet

• Priorities for items from last Wednesday (from right before going live):

  • Allowing Board Members to edit non-generated-pages
  • 200 proposals in CSV form
  • Reconfiguring Backups: Karl to work with Jason and Frank on this
  • Force embedded videos to start from the right video
  • Flask App
  • Deferred for now:
    • UI indication that a Wild Card has been chosen
    • Related Proposals: shelve for now
    • Deferred until Jason and Frank and OTS decide

2019-11-20 Consolidated notes from various Regina/Frank/Karl meetings.

Consolidated notes from today's various meetings, in preparation for Board Wild Card Selection going live tomorrow.

• Diagnosed the page-link capitalization problem and fixed.

  Look for the slew of edits by Regina and Karl this afternoon on the Lists and Collections page and all will become clear.

• Reformatted the Comparable Proposals page.

  Regina and Karl did this together.

• Proposal 9234 (the duplicate) is still found in some hand-written lists.

  Regina will find those and take care of them.

• Put a space into "Wild Card" (singular and plural).

  Regina and Karl did this in the Sidebar where we could. Frank will take care of the necessary updates to the extension to finish the job. Note that the "EligibleWildcards" page is now "Eligible_Wild_Cards" (and some code which looks for that specific page will therefore need to be adjusted, but Frank's on it).

• Move "Wildcards" above "Print/Export" in the Sidebar

  Frank will do.

• Make "Tools" section in Sidebar not be shown to Board members.

  We'll try to do that, but not promising it.

• In Sidebar, changed "Main page" to "Main Page".

  In the Sidebar control page that item is mainpage|mainpage-description. That's because the "mainpage-description" variable exists for internationalization/localization. So Frank just changed it to "Main Page" and now it's done.

• Protect against editing of generated pages.

  For example, the TOC pages got hand-edited to undo the text-justification of the rank number in some cases. Was this deliberate? It's fine, but it also raises the larger question of whether generated pages should be hand-editable.

  Decision by Regina: make them not be editable.

  Frank is changing the system so that generated pages will not be editable by anyone except the local-login "Admin" user. (Technical note: he's doing this by having csv2wiki make an API call that says "make this page read-only".)

• Normal login and user-masquerade ability for Karl

  Frank is doing this, so that Karl can view things as a Board Member would see them.

• Fixed rank number formatting on the Exemplary page.

  Karl did this manually (i.e., via Emacs)

• Regina will tell MacFound IT when Board members should get access

  MacFound IT will give them the necessary Okta chiclet.

• Monday morning, Dec. 16th, Board Member access will be shut off.

  Regina will tell MacFound IT to make sure the Okta chiclet goes away at that time, and Frank will flush any cookies early Monday morning so that any ongoing sessions get shut out. Frank will email Regina and Karl when he has done so.

• Long term: OTS to Look into whether MediaWiki page titles can be case-insensitive.

  Apparently the answer is yes: they can be case-insensitive, however transitioning to case-insensitivity from an existing wiki might require a multi-step dance. Some information is here and here.

2019-11-18 Consolidated notes from various meetings on demo day.

Today is demo day. Frank and Karl had some conversations in the morning, then Jeff and Karl checked in, then Frank and Karl checked in again about what Jeff and Karl checked in about, and then they checked in again later. Got that? Good. Below are the consolidated notes from all of this.

• SDGs are fixed. Yay.

• Added visual indicator of wildcard eligibility.

  On all TOC pages and in each proposal's snapshot.

• TOC pages now label the rank numbers with the word "rank".

• TOC pages now show group counts in parentheses.

  Including on the Countries and Regions TOC page, where the group count is shown for each grouping level.

• Bibliography sections are now more readable.

  Frank noticed that in the source data, the bibliography column has a line-break pattern that's reliable enough to use as a delimiter. We're now taking advantage of that, so that the formatting of the "Bibliography" section on each proposal is more readable than it used to be.

• Use "Topic_TOC" page as the "Proposals by Topic" page now.

  "Topic_TOC" is now used where we used to use "2010_100&Change_TOC". We've updated the Sidebar, and also added a new "Proposals by Topic" entry to the Lists page, pointing to Topic_TOC.

• Removed "Download as PDF" from the production sidebar.

• Jeff has confirmed that production sidebar is as he wants it.

• Jeff's ability to edit the sidebar is restored (nostra culpa).

• We made a server landing page.

  It still needs to get ansibilized, and Frank/Jason/Karl will figure out the right place to put the template -- it's for the whole server, not just for one specific wiki. See /var/www/html/README for notes.

• Two proposals have anamoulous coding errors. Can we fix in source data?

  These are mentioned in Feature Requests:

  • See the Organization Name in the snapshot for proposal 829.
  • Search for "xx x x x x x x x xx xxx" and "#NAME?" in proposal 5539.

  We've confirmed that these issues are in the source data. We would very much prefer to get these corrected at the source (i.e., for LfC to give us updated spreadsheets with these fixed), because that's always better than having Yet Another Special Case in our ETL code.

• Faceted search by category (a.k.a multi-category search) will be done later.

• Some symlinks in /var/www/html/ have double slashes in their targets.

  Although the double slash has no consequences that we know of, Frank will update the scripts to know which side is responsible for carrying the slash, so we don't get this side-effect when concatenating path components.

• "Population_TOC" is postponed.

  This came in too late to be done for demo.

  See this mail for details of what it is:

    From: Jeff Ubois
    Subject: Category pages 
    To: Karl Fogel, Frank Duncan
    Date: Mon, 18 Nov 2019 15:08:16 +0000
    Message-ID: <[email protected]>
  

• In the long run, LfC needs its own dedicated staging server.

  LfC really needs second production (i.e., customer staging) instance server, where they can do work and then "promote" it to the Board-facing production server.

    From: Jeff Ubois
    Subject: Re: 11/17 Morning Update
    To: Karl Fogel
    CC: Frank Duncan
    Date: Mon, 18 Nov 2019 02:24:14 +0000
    Message-ID: <[email protected]>
  

  We should discuss soon setting up and maintening another instance.

• "Lists organizing Wild Card Eligible Proposals" is postponed till after demo:

  On the Feature Requests page, we haven't yet implemented these and won't until after demos:

  • Wild Card Eligible Proposals Comparable to Top 100 Proposals
  • Wild Card Eligible Proposals Ranked Highly by Applicant to Applicant Review Panel
  • Wild Card Eligible Proposals That Did Not Score Highly in Applicant to Applicant Review
  • Wild Card Eligible Non-US Based NGO-led Projects

• "Lists organizing All Proposals", however, is done.

  To the best of our knowledge, all of these are done now:

  • Top Ranked by Geography
  • Top Ranked by Field
  • Top Ranked by SDG
  • Top Ranked by Organization-Type
  • Top 200 Proposals from 2016 100&Change Competition (LFC to provide)

  For that last one, LfC decided just to leave the 2016 proposals on the old site and have people refer there if they need to.

  For "Field", that's just the Topic_TOC page.

  For "Organization-Type", the For Profit organization list page does what they need.

• Confidential to OTS: double-check on backups for the production server.

  Karl will do with Jason.

2019-11-15 Jeff/Frank/Karl check-in.

• Proposal swap

  Problem: Proposal numbers 8782 (ranked #56) and 9234 (ranked #130) are duplicates.

  Solution: Remove 9234 from Torque, but don't then shift other proposals; instead, eligible wildcards will just go to rank #201 now.

  Frank said he will delete proposal 9234 from the production wiki manually, remove the corresponding 9234 line in the Wise Heads spreadsheet, and in compose-csvs change the threshold from "<= 200" to "<= 201". Then re-running the proposal ETL pipeline should Do The Right Thing. This should all happen by some time tomorrow (Saturday) morning.

• New Okta group

  The three groups we currently have are:

  • Board Members (MacFound board members)
  • Pseudo Board Members (people who offer support to the board)
  • LFC Torque (staff from LFC and MacArthur)

  We'll create a new group:

  • LFC Torque Admin (same as "LFC Torque" but can also view Wildcard selections.)

  People in this group are senior LfC staff, and Frank.

  Jeff will email Keith to get that group created, and to let Keith know that Frank should be in that group.

  This new access control group is not needed by Monday; by Wednesday is fine.

• Decisions about who can edit what

  • Regular pages: Everyone can edit, including board members.

  • System pages (pages that begin with "MediaWiki:", e.g., the sidebar): Only "LFC Torque" and "LFC Torque Admin" can edit

  • Generated pages (e.g., category pages, proposal pages, and TOCs): No one can edit these.

• Priorities for Monday

  • Absolutely needed:

    • Update PickSome to have "Select Wildcards" be the verbiage.
    • Show rank and total scores in snapshot box.
    • Change title of "Evaluation" section to "Peer to Peer Review".

  • These would be really good to have:

    • Create countries/subregions categorization.
    • Use domain specific words in category pages.
    • Auto generate interesting lists of categories.

  • Nice to have:

    • Insert pdf page breaks before comments sections.
    • Make proposals non editable by anyone, enable board members to edit other pages.
    • Give LFC top 200 proposals in csv form (maybe after monday?).

• New feature: "Related Proposals" section in each proposal page

  If Frank has time, he will add a new "Related Proposals" section to each proposal page. Within that new section is a subsection for each axis of relatedness (i.e., category) that can connect proposals, like SDG, Country, Region, etc. (In other words, each subsections is similar to a corresponding Category page.) The idea is to remove one click from the path of getting from a given proposal to all the other proposals related to it in a certain way.

• Accessibility tester Bruce Paul is ready.

  Frank, I'll send you a private email about this. Bruce Paul will do some a11y testing for us, and he is ready to receive login information for the dev wiki once the dev wiki is up-to-date. Bruce and I have already arranged a wiki user password for him; my followup email will explain to you where to find it.

2019-11-14 Frank/Karl check-in.

• Authn: we'll just have a special URL for alternate (non-Okta) login, for our bots and OTS staff and such. Frank will file a ticket about the dream scenario in which Okta and pluggable auth somehow cooperate with each other such that when an Okta login attempt fails because this user doesn't use Okta then the system just falls back to another login method. We don't actually know that this dream is even really possible, because of how Okta works, but we want to at least memorialize it and have a starting point for future research.

• Migration of 2016 competition data will take place later. For now, we can leave that stuff at macfound.opentechstrategies.com.

• LfC should have its own "/lfc" landing page (https://torque.leverforchange.org/lfc/) because Lever for Change may eventually have other partners with their own separate wikis.

• Front page of torque.leverforchange.org will just be a static landing page that explains what this site is and links to the wikis on it (or to the ones whose existence is not secret, anyway). Frank will draft up a quick page and not worry too much about appearances; Karl will tweak it afterwards.

• Karl will talk with Jeff about whether we want one overall LfC wiki or one LfC wiki per competition year. Karl will also talk to Jeff about what phases of production visibility staff would like.

• Karl will make a note in the Torque DESIGN.md file about how we deal with the possibility that a redeployment might overwrite users' changes to Ansible-originated pages.

2019-11-11 Jeff/Frank/Karl check-in.

These are combined notes from the Frank/Karl internal check-in of this morning and then our afternoon meeting with Jeff. Some of the items below are things that we already knew about, are in previous meetings' notes, and were already on the todo list. We reiterate them here just a way of saying "Yes, this is still on the list and we talked about it in today."

• Beginning-of-day on Monday, November 18th is production go-live date.

  We will do a review at beginning-of-day Friday, November 15th to check over UI and review priorities and statuses.

• Jeff will introduce OTS to Ken Woodhouse, the Board Liason, who will help us handle Board requests while Jeff is in Europe (18th - 25th).

• Ken Woodhouse may be able to help us test Board login and authorization on the production server, since we can't test logging in as a member of the actual "Board Members" group (we can only test logging in as a member of the special "Board Members Torque" group).

• Frank needs to lock down the SimpleSAML app on our server. We don't know much about its security profile, but, you know, it's some random PHP app exposed to the web, so let's assume that some tightening up is needed.

• Frank and Jason will be working out a consistent, ansiblized way to deploy to dev / staging / prod.

• Change the visible title of "Pick Some" to "Select Wildcards".

• Restrict the Select Wildcards functionality to just the proposals in the Second 100.

• Make sure that automatic login with Okta continues to work even while our csv2wiki bot can still log in the old way to make its API calls. This implies doing some more research into the Mediawiki pluggable auth system. Karl said (paraphrased) "Surely, no one would design an pluggable authentication system in which there's no way for a registered authn method to fail gracefully and pass control back to so that other methods can be tried? Right?" Frank and Karl agreed that of course no one would design a pluggable auth system that way.

• Give LfC back a CSV of just the Top 200 proposals. That is, after we've determined the Top 200 set (by ranking the proposals based on the Wise Heads scores), do a "join" back to the original CSV keyed on the proposal review number, and produce a filtered Top-200 CSV that has the same columns as the original CSV but only 200 data rows. Do not include the rankings in this CSV: we're just filtering an existing dataset based on some out-of-band data (the rankings).

  However, add a new "Wiki Page URL" column that contains the full URL to the production wiki page for that row's proposal.

  This new CSV will be generated as an extra output from the current ETL pipeline. We're going to make this file itself downloadable from the wiki. (And for now, we assume that we're not making the original, way-more-than-200-rows CSV also available for download)

  Since the original CSV is named Export-reg-and-app-data-Submission-deadline-06082019.csv, let's call the new file Export-reg-and-app-data-Submission-deadline-06082019-Top-200.csv, to make it crystal clear what original file it derives from. (We may revisit this filename decision with LfC before it goes live, of course, but for now let's go with this information-preserving name.)

• DECISION: We will leave the staging site data as-is.

  That is, we will not refresh the staging site to just include the Top 200 proposals. LfC needs a convenient place they can go back to to look at the other proposals from time to time.

• Auto-generate certain predefined Lists (Categories) pages, and order them by rank.

  See the "Lists" section in the Feature Requests page, with subsections "Lists organizing All Proposals" and "Lists organizing Wild Card Eligible Proposals", for details about this. Note that for some of these lists, there's more information we'll need to get from LfC before we can generate the appropriate list.

  On each list page, order the proposals shown by rank, and display the rank next to the proposal name.

  (Karl believes that this item is the same as one that he had earlier notes for. Those notes said: Right now, this page lists all the category pages, but the categories there include topics, locations, SDGs, etc... Is there an easy way to pull those apart, i.e., to make a separate pages for each category?" He's pretty sure that's just this same thing.)

• We went over the various "UI nits".

  These are now collected in the section "Priority feature requests before 11/18" in the Feature Requests page.

  • "Pick Some" should become "Select Wildcards" in all user-visible places.

  • In generated PDF, insert a page break before the start of the Wise Heads comments section and before the Peer Judges comments section. This could be as simple as adding <!-- PAGE BREAK --> at the corresponding points in the MediaWiki pages; see this PdfBook Extension documentation for more information. (But since we're using Collections/mwlib to print, does that PdfBook extension feature apply to us? We'll see.)

  • If possible, give a UI indication that a proposal is in the Top 100 in all places where the title is shown. (Need to do some MedieWiki CSS research to see if that's the easiest way to accomplish this.)

    This might or might not involve the infamous 100 emoji.

  • Include "Rank" and "Total Score" in the snapshot sidebox.

    Remember, the relevant scores should come from Wise Heads not from Peer Judges, now that we have the Wise Heads data.

  • Fix the "Application" link in the snapshot.

    This is actually already fixed, so it should be fine when the data is loaded into the production site.

  • If possible, make all proposal pages non-editable (by anyone).

    Instead of making it so Board Members can't edit, just make it so the proposal pages can't be edited by anyone and therefore don't show any edit controls (i.e., they have the same simplified view they have right now for Board Members).

    This would be a switch: currently we conditionalize those pages' appearance and editability based on who is logged in, and instead we want to do by what the page is (no matter who the user is).

  • If possible, use domain-specific words on Category pages.

    That is, instead of saying "Category" say "Country" (or "Topic" or "SDG" or whatever the more user-friendly word is for that category. This is just about the content of these pages -- it's okay that the page's URL still has "Category:" in it.

• If possible, fix the YouTube reload issue.

  Is there a way to hard-force the embedded YouTube videos to show the video we specified (rather than YouTube's idea of the "next recommended video") when a page reload is done after the video has already been viewed?

• There are some PDF accessibility issues; learn more, fix if possible

  See issue #12 for details.

2019-11-04 Frank/Karl sync-up re very near-term development.

Agenda and known todo items (from the "Wiki input from Cecilia" thread):

• Okta: How do we get to Scenario Two (as described here?

  Tomorrow morning (2019-11-05) Frank will try using the setup Keith suggested, and report back to Keith, and hopefully it'll all work. If it doesn't, he'll work with Keith to figure out what's needed.

• In Snapshot box, show "Rank" and "Total Score" fields from the "Evaluation" section.

  Frank will do. This is easy.

• In left side nav, rename PickSome to "Pick Wild Cards" or "Select Wild Cards".

  We will make it a configurable string that we document and declare. Specifically, the "Some" in "PickSome" will be treated as the thing that needs configuring here. We'll just do a partial generalization at this point, and not carry it to the fully general point (in which the DB table stops being named "PickSome" and instead there are multiple tables each named after the thing being picked, or else a new column in the DB; and an array of configuration options; etc), BUT, Frank will file an issue about the remaining generalization work that would, in an ideal world, be done.

• Ensure there are Top 100 and a Second 100 TOC pages.

  This is already on Frank's list for right after Okta, so will get done ASAP.

• Make proposals from Top 100 not selectable as Wild Card picks?

  The most common way to do this is to provide a callback function that asks "Is this page valid?". That callback function could either consult a list of valid pages (or for that matter of invalid pages), or it could actually parse the page and look for whether the page's "Total Score" field is in a certain range. We'll probably do the first way, because it's easy and straightforward.

  This is on the list for after Okta and after the item directly above this one. Frank says should be done by Friday.

• Change the title of the "Evaluation" section to "Peer to Peer Review".

  Frank, this is new, that is, from after our phone call tonight. I added it here after seeing it on the Feature Requests page (and removed it from there). I figured it should be pretty easy :-).

• Please check the "UI fixes and updates" section on Feature Requests.

  This is also new, from after our phone call tonight. It is lower priority than everything else above. Basically, there are a number of buglets described in the "UI fixes and updates" section on the Feature Requests page. We should see which ones still reproduce and fix them (or add a comment explaining why either it's not a bug or we shouldn't prioritize fixing it right now).

  For now, please mark items as fixed (or otherwise handled) on that page, but don't remove items. I'll remove them after making sure LfC is aware of what's fixed and what's not.

2019-10-30 Frank/Karl sync-up re near-term development.

• Data load for the Judge Reviews

  Done and looks good. Yay.

• Okta SimpleSAML integration.

  Highest priority right now. Frank is debugging a loop-loop problem between Okta and MediaWiki's SAML. We will check in tomorrow to see how debugging is going.

• Categorizing by Regions. Createing Tables of Contents for Top 100, Bottom 100, by Topic, by SDG, by Location.

  Deferred until Okta integration is done. These things are not expected to be hard, as they're basically the same as things we've already done with other data fields.

• Production Server setup

  Karl has started a thread on infra about doing this in an ansibilized way, and doing the initial configuration such that future expansion (i.e., other partners with their own wikis) is possible.

• Issue #10: deletion of associated comments when a page gets deleted

  Agreed to defer; not urgent.

• Flask App TorqueData project start

  Will start after Board features are done and deployed to production.

2019-10-24 LfC/OTS sync-up re everything.

First, an overview of the kinds of data we have.

1. Peer-to-peer judging data. This is both quantative and qualitative, and we have it all already (though perhaps we'll get a minor update of the data at some point, as stragglers come in).

2. Wise Heads evaluational panel data. Also both quantitative and qualitative. We don't have it yet (?), at least not all of it.

3. Technical Review data. Mostly qualitative prose, but there's one semi-qualitative "red/yellow/green overall good feeling" indicator, which we'll want to display a nice way with like a red/yellow/green solid circle or something. We also don't have this data yet because, obviously, Technical Review hasn't happened yet.

Schedule of what's coming and how we'll support it.

Judging process will be done soon -- was supposed to be this week, might take a bit longer. We already have most of the data (it's in P2P-review-data-20190929-for-OTS-copy.csv.asc, by the way).

Wildcard Review is scheduled for 12-26 November. We should assume it will be those dates, although in practice it may be delayed a bit if the completion of the peer-to-peer judging is delayed.

What we need for Wildcard Review:

1. Okta finished and in production.

   Hopefully we will get from Okta a field saying whether a given logged-in person is a Board Member, or a Staff Member, etc. Since all Board Members are participating in Wildcard Review, we don't need an explicit whitelist for them: if this user is a Board Member, then they get the Board Member view of the wiki.

   With Staff Members it's a little more complicated: since not all staff will be working in the system, we will need to whitelist the ones that are. So for staff, the test is "Does Okta say this is a staff member and is this person on the staff whitelist?"

2. De-slushing: Refresh the wiki so that just the top 200 proposals are in it, one TOC page for 1-100, and another TOC for 101-200. (After this process is all done, we'll put the slush pile back, and staff will let us know when it's time to do that.)

Technical Review comes after Wildcard Review. For Technical Review, we have a new single TOC with just the final 120 proposals: the original top 100, plus the 20 picks -- 2 per Board Member -- from 101-200. The remaining 80 are still in the wiki, but they're not listed on this new TOC page.

Tech Reviewers (TRs) do not log in to the wiki. They're sending in their materia via a separate system, and we'll get it in a CSV, which we will incorporate into our data pipeline and thence into the proposal pages. There is 1 TR per proposal. Although the TR's name will be in the CSV, we shouldn't include the name in the wiki page.

Handling authorization.

The Board deliberates in private with staff (or at least all staff who have access to the wiki in the first place). So, comments are visible to both board members and staff members.

No Technical Reviewers will be logging in.

So, authz needs for next will be completed when Okta integration is completed. The bigger core-database-API work can go on in parallel. It will support more sophisticated authz, and we'll have to discuss that some more, but that doesn't need to be implemented for Wildcard Review or Technical Review.

Integration of judges's scores and comments.

Judges trait scoring is in P2P-review-data-20190929-for-OTS-copy.csv (which is now stored encrypted in our private bigdata area).

There are four traits, each of which is evaluated independently, per proposal, by 5 judges:

• Impactful
• Evidence-based
• Feasible
• Durable

We should present them more or less the way the old wiki did (see some examples here). That is, on given proposal, display the total all-traits normalized score (SumOfScoresNormalized), then each trait's normalized score by trait (TraitScoreNormalized) either summed or averaged across all the judges (not sure which -- ask LfC), and then all the judge's comments for that trait (list ``TraitJudgeComment` under each trait) anonymously.

Thus the columns we really care about in in that spreadsheet are going to be:

• Application #
• OverallScoreRankNormalized (rank this proposal is in when you look at its SumOfScoresNormalized)
• SumOfScoresNormalized
• TraitScoreNormalized
• TraitJudgeComment
• Trait

(Note we can ignore all the non-normalized scores: OverallScoreRank, SumOfScores, TraitScore.)

Handling Geographic Regions

We'll have:

• One SDG page
• One Topic Categories page
• One Geographic Location Categories page (divided into regions, then countries within each region).

Note that https://macfound.opentechstrategies.com/lfc/index.php/Lists currently points to https://macfound.opentechstrategies.com/lfc/index.php/Special:Categories, and the latter is a bad user experience because it's no longer just topics -- instead, topic-categories and geo-categories are confusingly interleaved. We'll need to generate better pages and point to them, hence the above plan.

Geo information comes from these fields in the proposals:

• Headquarters
• Future of Work Locations (1-5 or so)
• Current Work Locatation (1-5 or so)

Action items coming out of this meeting.

• Karl to give DevOps the IP address (209.97.145.113) of the server that will be torque.leverforchange.org so they tweak DNS. (macfound.opentechstrategies.com will then become our staging server.)

• (Done) Karl to talk to Jason about spinning up that server.

• (Done) Karl and Frank to determine what the unplanned work has been, so Karl can send to Jeff to discuss with Cecilia et al, so we can improve this style of quick-cycle responsive iterative development. Some of the things: the geo stuff, categories search, data presentation questions take a long time to decide and the decision process is very involved. Note also, though, that some things get dropped, so there is some balance: for example voting/polling went away.

• (Done -- filed issue #10) Look at having TeamComments hook into the MediaWiki page deletion API so that associated comments are deleted when a page is deleted.

2019-10-07 Frank/Karl sync-up re Okta, mwlib, and more.

• The new borders and background highlighting for comments are terrific. Perfect.

• Frank spoke to Okta after the initial trial period expiration, and got from them a pointer to their (apparently unadvertised) dev gateway, which he's now drawing on.

• Do the initial Okta implementation (which looks to be pretty simple), document it, and check it with LfC. It's possible they may need a slightly different way, but the basics of the integration should be as Okta recommended.

• Estmate effort needed to port mwlib from Python 2 to 3. We discussed that option versus getting the Collections extension to work with Proton (the new rendering engine: https://phabricator.wikimedia.org/project/view/2960/). It's not clear yet which route we should take, but getting a rough LOE for the mwlib upgrade is a good place to start.

• Implement Countries as Categories, with each country name in a proposal linking to the corresponding Category page for that country. We may later also have special category-specific TOC pages, but this is independent of that.

2019-09-30 Frank/Karl sync-up re commenting system etc.

• Fix attachments links (it's an ansible problem), then contact MacFound devops to say that ansible configuration is now in a working state (though not in a final state, of course).

• Give TeamComments the standard MediaWiki extension documentation.

• Nest the blockquotes in the reply edit box. (Done during call.)

• Put Permalink link up by the comment's header (where author+date are), but leave Reply/Edit/Delete down at the bottom of the comment.

• Change default height of Reply edit window from 150 to 300.

• When you refresh a page while a comment or reply is under way, you lose the text. Frank will fix it so that when you get the "new comment has come in; would you like to refresh now?" box (that's not an exact quote, but hey, we all know which which notification box I'm talking about), clicking refresh there preserves any text in the comment edit window. For any other kind of page refresh, there will be a warning about how you're about to lose that text, so you should go save it somewhere out-of-band now if you want to keep it.

• Confirmed that comments should not show up in PDF generation, and that this should be controlled from whoever is generating the comments tag (e.g., in sec_map, we'd wrap the comments tag in a div with some attribute=noprint in it).

• We'll create our own wiki syntax cheat sheet (deriving from https://en.wikipedia.org/wiki/Help:Cheatsheet) that focuses on what's most important for our users. Frank will supply the ansible hookup; Karl will supply the content.

• File an issue about double-checking security concerns re users inserting (or being blocked from inserting) arbitrary JS and whatnot via comments into pages that others load. MediaWiki seems to protect in the right way against this, but we should take a closer look and make sure, so that it's safe to expand usage of this system beyond a trusted user base.

• Deploy the TeamComments improvements to prod ASAP.

• Get the rank scores into the wiki, in a first draft for Jeff and team to give feedback on. Point out to Jeff et al that the scores will be visible to everyone, which may need to change at some point down the road.

2019-09-26 LfC / OTS meeting about next steps and roadmap.

Attendees: Chris Andreen, Keith Krellwitz, Jeff Ubois, Frank Duncan, Karl Fogel

• LfC will continue their dockerization and will contribute the docker configurations to the public torque project. OTS will continue using Ansible for dev instance setup, and the Ansible config files may help inform the Docker config (or for that matter vice versa), but the two will be independent and maintained in parallel.

  In practice, this is unlikely to be a dual-maintenance problem in practice because a) the configs track each other, b) they're not very complex, c) they don't change very often, and d) if something gets out-of-date or broken, it will be obvious very quickly and the solution will be easily at hand in the other config.

  Note that LfC got some of the configuration information from the wiki itself and will add information from Ansible to that mix as needed.

• Jeff has continued to update the FeatureRequests page in the wiki; Karl should check that periodically and migrate things into project management structure (e.g., issues, etc) as needed.

• Sorted out various questions about Okta integration. Frank knows what to do. Karl, who is typing this in from handwritten notes, didn't capture the details, but the basic picture seems to be that we'll start with authentication, and then we'll talk again about how to coordinate authorization via SimpleSAML and wiki roles (and we didn't anticipate any major problems with this).

  • Frank Notes: Continue along getting a working okta integration local to OTS side, so we know what we're talking about as we talk about with them. Then investigate how users need to be federated, if at all, within mediawiki.

• OTS to explore whether it's possible to do faceted search in Mediawiki (is there a plugin?) in order to, essentially, treat the wiki pages as a spreadsheet or structured data store.

• In the Country fields (e.g., current country, future work country, etc), make the values be links to per-country Category pages that show all the proposals that are associated (via any of those country fields) with that country.

  Furthermore, look for other fields whose values are likewise restricted to some kind of controlled vocabulary and determine whether it makes sense to do a similar thing with them.

  • Frank Notes: This relates to the previous faceted search, but there are extensions that allow multi category search, and it seems like most of the queries are rigorously defined in terms of those categories: "I want clean water proposals related to India"

• Some discussion of the benefits and costs of iterative development, and the possibility that continuing these tight high-touch feedback cycles -- and the unexpected enhancements and features they sometimes lead to -- may require some reshaping of the SOW. There was no need to reach any conclusions about that today, so we didn't, (and hey, such conclusions wouldn't go in a public wiki anyway), but this item is just to note that we talked about it.

• Karl to send email to Chris and Keith about possibility of piggybacking on the CSV data-cleaning code for analytics purposes. For example, we produce a final CSV (conceptually, it's the result of a "join"), and it might be easier for them to do analytics on that final CSV than on any of the input CSVs.

• Frank Notes: API is a big unknown. But, it looks like it's going to be important to do. Things that were listed during meeting that are open questions

  • Data authorization management is a large concern
  • Who houses the data? mediawiki certainly can, but if it isn't then maybe instead of pulling from csvs, it should pull from a database?
  • The different consumers of the API don't have rigorous requirements with how they are going to use it, and what information they need to have, or even can have.

  In that email, also mention the possibility of renaming the MacFound repository to something that reflects LfC (not sure anyone cares one way or the other, but it's worth asking).

  Also, mention Zulip chat channel availability for real-time conversation.

  Send this email to the MacFound devops {AT} macfound.org address.

2019-09-19 Frank/Karl sync-up about commenting system, etc.

Decisions about commenting system

We'll fork the "Comments" plugin (see the evaluation of MediaWiki commenting plugins) and make the following changes to it:

• Have a clear separator before the comments section begins

  Have a header that says "Comments", but only have that header present if comments are actually enabled.

• Runtime config option to toggle comments on/off.

• Distinctive visual appearance for comments area Use a background like the Wildcard Choices box has.

• Authz: Who views/writes comments?

  Out-of-the-box, there are perms around posting comments, putting links into comments one posts, and deleting others' comments.

  But we need view/no-view authz control too.

• Be able to delete one's own comment.

  If it has no replies, just delete it. If it has replies, replace it with a short anonymous comment that just says "a comment was deleted" or something like that, and the orphaned replies can remain as replies.

• Be able to post-facto edit one's own comment.

  Would be nice to have this, if it's not a huge lift. If it's a ton of work, put it off for now, though.

• Get rid of the sort-by option at the top.

  Just use chronological order.

  We may revisit the idea of doing reverse-chronological for the thread-top-level ordering while regular chronological for the replies underneath that top level. But for now, let's just go with chronological for everything, because that handles everything correctly by default.

• Get rid of the scoring upvote/downvote arrows.

• Get rid of the missing-person pictures.

  This may spur some other design changes, and that's okay.

• Get rid of the "ignore" icon (the red "Ø" symbol)

• Timestamps like "16 September 2019, at 19:11" (not "37 minutes ago").

• Enable auto-refresh by default

  And get rid of the "enable/pause comment auto-refresher" link at the top of the comments section. Also, don't auto-jump to #end when a new comment appears. A good option is to do the GitHub-style "2 new comments have appeared since you last refreshed. Refresh now?" thing.

• Use constant nesting level for all replies.

  Quote original message, with angle brackets, and link to original message.

• Permalink jump should style-highlight target.

  When someone clicks on a comment permalink, not only take them to that comment but highlight around it (red box) so that it's clear exactly what comment they went to.

Rename our custom plugins; update their DB table names, etc.

• PickSome (Wildcard / pick-two)
• SimpleWatch (Favorites)
• TeamComments (our fork of Comments)

Back-end improvements to PickSome

• Configurablize the number 2

• i18n-ize