[meta] Website for Fellowship Program

RESOLVED FIXED

Status

enhancement
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: dtate, Unassigned)

Tracking

({meta})

Details

(Whiteboard: [specification][type:feature])

User Story

What is the core reason for this to exist -- if we do this, we succeed?
Phase 1: to promote the program and to attract great applicants

Minimal requirements for phase 1:
* Website hosted at https://developer.mozilla.org/fellowships (or similar)
* Includes link to fellowship application hosted on SurveyGizmo
* Social media share buttons on each page

Nice to have in phase 1:
1) It is not publicly editable
2) Its design is derived from MDNs

Things that don’t matter:
* Whether or not MDN nav is up top of the site
* Whether the rest of the MDN header is there (including signed in/out state)
* Whether the site's look & feel are significantly distinct from MDN’s
* Whether content can be edited without Github

Attachments

(2 attachments)

What problems would this solve?
===============================
Lack of awareness of Fellowship program to be launched
A way to apply to the program 

Who would use this?
===================
MDN community to promote the program
Fellows


What would users see?
=====================
Overview - description of the program
Benefits
FAQs
Application Form
Contact Us
Social media buttons 

What would users do? What would happen as a result?
===================================================
Read about the program
Refer it to others and/or apply themselves

Is there anything else we should know?
======================================
We have discussed creating static Django pages on MDN as there is a preference to 'house' the site on MDN as it is an MDN program.

Reference sites (for general architecture) include:

and per Justin's questions:
* How many pages does the microsite have? 
5 - see above "What Would Users See?")

* Does it need a fancy design? Is a design bug filed?
Nothing fancy - these examples would be a good general direction for information architecture - e.g. very basic - but ideally keeping the look  feel of MDN:
https://advocacy.mozilla.org/open-web-fellows/
https://webfwd.org/
 
* Are we collecting info? Which info? Is a project review bug filed?
Yes - we will have an application form that will ask for contact info, Github portfolio and a few essay questions on how the Fellow is a fit for the program.

* Is the copy done? If not, when will it be done?
Whenever it needs to be :) - if the clock starts now, I can prob pull it together in 1 week. Also, if I can make copy changes to the site myself that'd be lovely (CMS??) 

* When is the drop-dead launch date and what is driving that date?
End of Q1 is when we committed to launch the program so: end of Q1.
Thanks for filing!

What about localization? What languages will it need to be localized into?
Why a specific web site and not a zone on MDN?
Flags: needinfo?(dtate)
Justin: English should be fine for now.

Jean-Yves: Luke said zones are not possible since they have restricted layouts, markups, and styles.
Flags: needinfo?(dtate)
I chatted with Diane about the minimum requirements of this site. An excerpt from our conversation is below:

What is the core reason for this to exist -- if we do this, we succeed?
Phase 1: to promote the program and to attract great applicants

Minimal requirements for phase 1:
* Website hosted at https://developer.mozilla.org/fellowships (or similar)
* Includes link to fellowship application hosted on SurveyGizmo
* Social media share buttons on each page

Nice to have in phase 1:
1) It is not publicly editable
2) Its design is derived from MDNs

After reviewing the requirements, I think the simplest implementation of this is either a Zone page or a static page. For example...
Zone: https://developer.mozilla.org/en-US/docs/Mozilla/Connect
Static: https://developer.mozilla.org/en-US/learn/javascript 

Questions for :groovecoder and others who know:
1) Which is a better approach, considering requirements: Zone page or static page (template)?
2) Are there layout constraints if we use a Zone page?
3) Are there any other constraints of either approach that should inform this decision?
Flags: needinfo?(lcrouch)
I forgot to include a critical set of bullets above.

Things that don’t matter:
* Whether or not MDN nav is up top of the site
* Whether the rest of the MDN header is there (including signed in/out state)
* Whether the site's look & feel are significantly distinct from MDN’s
* Whether content can be edited without Github

These are critical because they suggest that a solution built _inside_ kuma, whether as a static template or as content in the wiki, with headers/footers already built and understood, will satisfy the minimum requirements. And that, I think, will drastically diminish the scope of the project.
Severity: normal → enhancement
Keywords: meta
Summary: Website for Fellowship Program → [meta] Website for Fellowship Program
Filed Project Bug to cover the application form data per hoosteeno
https://bugzilla.mozilla.org/show_bug.cgi?id=1128021
Posted file Google Doc of copy
I talked with :groovecoder about potential solutions.

> 1) Which is a better approach, considering requirements: Zone page or static
> page (template)?

If we want to make it write-protected, a static template file is better. Furthermore, that is likely the approach that MDN engineers would prefer if they are doing implementation. Finally, that approach offers more flexibility of layout (which is either a feature or a risk, depending on where you're standing). 

> 2) Are there layout constraints if we use a Zone page?

Yes. See any zone page to get a sense of it. If admin, see "Manage Content Zone" to learn what is actually configurable (e.g. https://developer.mozilla.org/admin/wiki/documentzone/21/). 

Considering this feedback, my next step is to discuss these options with frontend engineers on MDN.
Flags: needinfo?(lcrouch)
User Story: (updated)
In lieu of an obvious planned project around this, I am going to suggest we gather the things we need (content, developers, project managers) however we can. I am working on the people side of this; getting content early will help.

:diane, can you source some art that you think this page should include? For example, it might benefit from a photo of Mozillians interacting or hacking or something like that. Think, "A picture that could be a picture of Fellows having a great time doing Fellow stuff". Ideas for this:

* I suspect there are some great photos from the Summit 2013 pool that would fit in well. Mardi or William R might know where to find them. We should also confirm (probably with Mardi) that any photo we select is licensed for our use, and its subjects have released the use of it in Mozilla marketing materials.

* If not that, the Reps program probably has some ideas. Rosana Ardila, William Q might both be folks to reach out to.

* Maybe someone who worked on WebFWD has access to pictures from WebFWD that would apply? :)

Standard photo dimensions are best. Large is best. Two or three options are best (that'll give us the most flexibility as we move forward).
Flags: needinfo?(dtate)
Ok two things: 

(1) I've updated the text doc as we hope to include the actual project descriptions -- is this where the 'design' help you mentioned we may need might play in e.g. layout? :)

(2) I also found a few photos in order of preference -- would they work technically, visually? If we use one of these I'll tripe check any permissions.

PHOTO OPTIONS:
Mies
https://www.flickr.com/photos/69751921@N07/8955355253/

Brock
https://www.flickr.com/photos/69751921@N07/8956554998/ (promise of the web)
https://www.flickr.com/photos/69751921@N07/8956547364/

Alban: https://www.flickr.com/photos/69751921@N07/8956548672/ 

Team shot (funky border may negate this one): https://www.flickr.com/photos/69751921@N07/8005474095/

MDN one!
https://www.flickr.com/photos/flod/2583815568/in/photolist-8hNpDp-4ohK9b-4HbqTQ-8GLVUk-qBGSw-8GQ6g3-8gPpBF-8hNpNi-4YvKGJ-5YCMxA-e88RTz-6aBJCU-4WjJmh-LpVD5-4WM1hB-8GQ5Dy-gnQsin-9RC7ox-59tYff-4YERN3-5mtXcK-5mtWZK-8xw1An-2M6UN-dRuMzt-5YCMAh-8gViUM-4VCoqn-65yvLk-cVCCzE-4mkicD-4Tq7JZ-mowNR-5YCMyU-guKFge-e19DqT-5LEt3V-8hGLnt-drXNBr-8YU98Y-4WxbPe-aDybGa-bibEXe-dXJPWG-jEkhny-ahtpXp-ee46Wg-9sMJ2X-5iLXo1-5gqyia (with attribution > https://creativecommons.org/licenses/by-nc-sa/2.0/)
Flags: needinfo?(dtate)
I am not sold on any of those images as a hero (i.e. the big eyecatching one). I don't think they inspire the feeling of "belonging to something bigger than yourself" that I think may be one of this program's compelling attractions. I think a picture with more than one person -- not posed -- might capture that better.

However, as a smaller image further down the page or as part of a multi-photo treatment, I think these are nice. They capture the "You will feel like a rockstar when you present your work at Mozilla" feeling that may attract others to the program.

My feedback should be taken with a grain of salt. If a skilled designer comes along they will have their own ideas. If a skilled designer does not come along I may end up building a McDonald's[0] mockup to get us going and then I will be picky about which images we use.

In any event, I'm going to break this into its own bug. Please direct further design/artwork discussion at bug 1129653.

[0] https://medium.com/@ienjoy/mcdonalds-theory-9216e1c9da7d
I added some photos to the art bug and have created the SurveyGizmo survey which I added to the (resolved) survey bug. Adding here  for good measure:
http://www.surveygizmo.com/s3/1998528/PILOT-Developer-Fellowship-Application
ok art submitted for review and copy still on track for finalization by Friday 2/13. Now for the fun part: the URL! Justin says I can pick. Here's some options (I'm fine with whatever you go with of these or happy to chat if these pose any issues!):

http://developer.mozilla.org/DevFellowship/Pilot
http://developer.mozilla.org/Fellowship/Pilot
http://developer.mozilla.org/Fellowship

(I wasn't sure if I could go to a 'child' page or not etc. so honestly whatever works!)
If there's no reason to go with a child page, I wouldn't now. You can always move it there later during the next round. Is the title of the program MDN Fellowships? If so, I'd vote for /Fellowship or /MDNFellowships which might be redundant given the first part of the url.
cool - unless anyone objects I like http://developer.mozilla.org/Fellowship myself :)
We need parent pages before we can have child ones :P Short and to the point I vote: http://developer.mozilla.org/Fellowship
Input from Jeffrey Garver, legal on our 'fine print' section which I've incorporated into the main copy document.
Added Jeff Garver (legal who provided copy for "Fine Print" section) and Maya Barrows (visas)
Stephanie: I tweaked the content in the Fellowship Doc to reflect new location & dates -- flagged in the doc in "Where" and "When" Sections:
https://docs.google.com/a/mozilla.com/document/d/1B2zng59WQD14I9NcB0OX8xb2sM9v-fx77gZ4hxIAVLQ/edit
Pull request is in, waiting for review now.
awesome - I assume you aren't waiting for my review but someone else's but if me, lmk!
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/268550aef80090c19f1d27078ffacbcb24d3c658
[fix bug 1126583] Add fellowship page

https://github.com/mozilla/kuma/commit/6cf84b143d99b0868a28ccdcef2398f76b7807cb
[fix bug 1126583]Add fellowship stylesheet

https://github.com/mozilla/kuma/commit/3296e46c51f961f7b2d4c3cc82270487e4d55642
[fix bug 1126583] Add share widget

https://github.com/mozilla/kuma/commit/5505946dd46e80751797171fee92d9f26dfa94e8
[fix bug 1126583] CSS tweaks

https://github.com/mozilla/kuma/commit/3a1c135c8ef56dc1e3d7ff6993ea4c853c7ed65f
[fix bug 1126583] Add image placeholder

https://github.com/mozilla/kuma/commit/1221909d211bf57e66ab754e7104358ab172528d
Fix Bug 1126583: Fellowship Site

- moved details/summary shim into wiki.js
- added and marked up finalized copy
- made share widget work with focus and touch and added a non-js fallback
- added apply now button to top, styled both apply now buttons to match share
- added correct share links to share widget
- hide languages drop down in footer

https://github.com/mozilla/kuma/commit/a3c09f07a049a097f44526f0669422bc6b664e76
Merge pull request #3087 from stephaniehobson/bug-1126583-fellowship

Fix Bug 1126583: Create Fellowship single page site.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
w00t! What URL is this now at? This doesn't seem to be turning up anything:
https://developer.mozilla.org/en-US/Fellowship
which means it has a nicer vanity url too: developer.mozilla.org/fellowship
SO sorry to make another text change but we just got word from Chris Beard that we should not do Orientation in Whistler. Until we work out the details, this should work for the 2 spots we mention Orientation:

Orientation: Early June (dates TBD)

Orientation: A Mozilla location (TBD)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
based on feedback from Luke on needing to make the "what's in it for developers" more prominent, we'd like to move the "Why" Section higher as follows:
Who
What 
*Why*
When
Where

thank you!
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/ea5ce693e1c72affed037160bde3ac6fadea5c5b
Fix Bug 1126583: Reorder Fellowship

Moved "Why" section up.

https://github.com/mozilla/kuma/commit/47de0dd9e500eed656be3ce51b8ae47995554173
Merge pull request #3108 from stephaniehobson/bug-1126583-reorder-fellowship

Fix Bug 1126583: Reorder Fellowship
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Reminder that on Thursday, April 2 we will need to remove the following items from https://developer.mozilla.org/en-US/fellowship:

1) "Apply Now" button at top of page
2) "Apply Now" button at bottom of page
3) "Applications are open now and we will accept them through April 1, 2015." text next to "Apply Now" button at bottom of page

Thank you!

Diane
I updated the waffle flag on prod, so the applications are now closed:

https://developer.mozilla.org/en-US/fellowship
You need to log in before you can comment on or make changes to this bug.