Scope MozFest site updates - June 1 Call for Proposals

[edrushka]

DARCI

Driver: @edrushka A: @xmatthewx R: @vazquez + dev?? C: @Saallen @lovegushwa

Overview

The MozFest website needs to be updated on June 1 so we can:

• open the call for proposals, which runs until Aug 1
• kick off ticket sales
• start providing details about the programming of this year's festival (e.g. identify some of the spaces) This 2-month period is the site's most trafficked time of the year.

  Links

MozFest website Planning etherpad Repo for website work

Key Deadlines

• [ ] May 6 Scope updates and begin design
• [ ] May 20 Complete design and begin dev
• [ ] May 30 Updates are live on site (2 days for QA)
• [ ] June 1 Call for MozFest session proposals opens

[edrushka]

Changes to the individual pages are being tracked here. Most of these are simple copy changes, which I will finalize in mid-May.

Design-wise, our plan is limited to 4 things: 1) Change image and mask colour on the landing page 2) Make call for proposal page spiffy & optimize CTA 3) Make ticket sales embedded thing spiffy 4) Design a blog page (We are postponing this until CMS is ready)

I can review with the assigned designer next week.

[edrushka]

@Saallen - we discussed this in our heartbeat kickoff and agreed that Mofo's custom CMS will be the best solution for the blog. However, the CMS likely won't be ready in time for the June 1st website update.

If we write or receive posts we want to post before the CMS is ready, a solution is to make temporary wordpress blog (e.g. mozfest.wordpress.com). Wordpress plays nice with our CMS, so we should be able to export the blog posts when it's ready.

Does this work for you?

@hannahkane can you please throw in an estimate for when the CMS might be ready to implement on the MozFest site?

[mmmavis]

It would be great if we can reserve 1-2 days dev time to upgrade libraries and frameworks used on mozillafestival.org as it's currently using very old react and react-router etc (see package.json). This is not a blocker to small site updates but since it will be a big jump to react v15 and react-router v2 it would be great if we can finish the upgrade before any major site change.

[Saallen]

:wolf: Sounds good to me @edrushka

[hannahkane]

@mmmavis might be able to help estimate the effort it would take to get the CMS up and running on the MozFest site. @mmmavis - do you have enough information to do that?

[edrushka]

We chatted about this in today's stand. Sounds like the CMS will be ready in July(-ish) so we can implement the blog page in one of our later website updates (e.g. when the call for proposals closes in August).

[hannahkane]

Where did the July estimate come from?

[edrushka]

I think I just pulled it out of thin air during one of our stands ;) It was framed as 'will this blog functionality be ready closer to July, or closer to September?' and I believe @xmatthewx @mmmavis were leaning towards July.

[mmmavis]

@mmmavis might be able to help estimate the effort it would take to get the CMS up and running on the MozFest site. @mmmavis - do you have enough information to do that?

Are we talking about setting up a WordPress instance (e.g., mozfest.wordpress.com), allow people to post blog posts there, and display the blog posts on the MozFest site?

[hannahkane]

@mmmavis - I'd meant the effort required to hook up the CMS to the MozFest website.

[mmmavis]

Sorry for this lengthy comment. I'm going on 2-week PTO soon so I thought it would be good to have a more detailed summary for people to refer to. :wink:

Here's the summary of the discussion we had last Thursday. (full Etherpad notes here)

Form submission

We should probably stay with using Google form as backend for the submission. Each Space should have its own Google form, this way we can include custom Space related questions. On the MozFest site we can create form that links to the Google form in the backend (ie., think of this as an embedded form). We can have a dropdown on MozFest site for Space selection and that will be used to toggle Space-specific question and the form destination (ie., which Google form it is tied to). (updated on May 10, according to @Saallen we will only use ONE form to take in proposals)

Instead of making Github account as a requirement, we should include a "Github handle" field in the forms so that when we batch export proposal data from Google Spreadsheet -> Github we can tag & mention the person who submitted the proposal.

When call for proposal ends

[Option 1] (takes less time to build but proposal curation will require more human effort) Like last year, batch export proposals(excluding private info) from Google Spreadsheet to Github.

Prefix Space labels and Pathway labels on Github.

For late submissions we can probably run the export script daily or manually copy the info over to Github (we should have a ticket template on the repo).

[Option 2] preferred (takes more time to build but will automate things a lot)

Instead of batch exporting from Google Spreadsheet to Github and manual exports for late submissions... Upon proposal submission we should use Github API to post a ticket (excluding personal info) to the session planning repo. That is, when people submit a proposal through MozFest site, (1) full proposal data goes to Google Spreadsheet and (2) a new proposal ticket (excluding private info) will be automatically filed to the session planning repo. Note that we should ensure the Github ticket also includes a reference to the Spreadsheet (eg., row number etc)

We will need to create a Github bot account to use the Github API.

Regardless of which option we choose, we need to empathize that the ticket format has to follow what we have in the ticket template. And the ticket description (first comment box) will be where we are extracting the session data from when we export data again from Github -> final spreadsheet.

/cc @Saallen @edrushka @acabunoc @xmatthewx @hannahkane @vazquez

[simonwex]

Hey @mmmavis do you mind commenting with the work you think will need to be done before you get back from PTO?

[mmmavis]

Hey @simonwex , I'm back from PTO on May 30th so I think we'll have to find another dev to implement this.

[mmmavis]

@simonwex I could start setting thing up next week before I go on PTO on Thursday but I doubt I would be able to finish the full implementation (plus we probably need @edrushka & @Saallen to provide details & requirements ). Maybe someone else can just take over my WIP work and wrap it up instead?

[hannahkane]

Just a note that I added #810 to the May 20 milestone.

[hannahkane]

@edrushka - I'm going to put this in the May 20 milestone so that we can close May 6

[mmmavis]

Chatted with @ScottDowne on this a bit (thanks for helping Scott! :bowtie: ). If time allows I think option 2 is the preferred approach. But I'll leave it for @ScottDowne to decide since option 2 does require more time to build.

I heard back from @Saallen - she said questions on the proposal form are still being discussed and triaged. @ScottDowne I would suggest checking with Sarah for the detailed specs when you get a chance 👍

[ScottDowne]

This is what last year's proposals page looked like while it was open, for anyone that might not be able to access it. We should reuse lots of it, and I'll work with @vazquez for any tweaks:

[ScottDowne]

This is what we should use(tweak if need be) for proposal submission success:

[ScottDowne]

I think I have two questions for @mmmavis

1. Where does the code live for last year's google doc to github issues migration script live.
2. Is the spreadsheet row number something we can rely on? Would it be better maybe to create a guid and send that to both the spreadsheet and the issue under an id of sorts field?

[mmmavis]

@ScottDowne

Where does the code live for last year's google doc to github issues migration script live.

The majority of the code is still in the current codebase. You can refer to this PR for the changes I made when Call for Proposals ended last year.

Is the spreadsheet row number something we can rely on? Would it be better maybe to create a guid and send that to both the spreadsheet and the issue under an id of sorts field?

Glad you mentioned! I was gonna mention this in my comment but forgot 😺 Yea, I think we should create a guid instead of relying on row number as row number can change.

[mmmavis]

@ScottDowne

Where does the code live for last year's google doc to github issues migration script live.

Oops, misread this question. The script lives here: https://github.com/mmmavis/test-mozfest-proposals-migrator. I suggest you do some testing first before running the actual proposals migration... I rushed to get this script up last year so it could be buggy... it should be usable 😁 I'll add some docs to the repo.

[ScottDowne]

@mmmavis sounds good. I don't think I'm going to have any issues with option 2.

[Saallen]

@ScottDowne and @vazquez I will set up a meeting with you both for next week to chat about the form, the new questions to be added and next steps.

[mmmavis]

Thanks team! 👍 🎉

(I'm checking out soon, YAY VACATION! 😉)

[edrushka]

@Saallen not sure if you'll have time for this in preparation for our Tuesday meeting but if you want to take those screengrabs Scott posted above, and use an image editor to indicate the changes you want on the form, that would work well. I can also help you with this after the meeting.

[edrushka]

Rolling this over to the next heartbeat rather than writing a new implementation ticket. Significant work has been accomplished and we're still on track to ship by June 1. Just a reminder that individual tickets are being tracked here: https://github.com/MozillaFoundation/2016.Mozillafestival.org/issues

[ScottDowne]

I talked to Erika, and I needed a bit more room to breath.

We're moving the email/github integration to a p2, that can actually happen after the initial proposals open. By a day or two later, absolute min is before London.

[Saallen]

@ScottDowne that is prefectly fine, as the integration can happen at a later date to the call opening. So we can email all submissions when we are set up and ready. Thanks!

[hannahkane]

@edrushka - Should this ticket be closed or move to an upcoming heartbeat?

[edrushka]

CLOSED! 💥 We shipped this on time. Thanks team! ❤️