outreachy / website Goto Github PK

Add to top of view template.

Right now, the menu items are listed in the order that the page was created (which is to say, seemingly random for a normal human). The menu order should be:

• Apply
• Mentor
• Sponsor
• Promote
• Alums
• Opportunities
• Contact

I think it could be fixed here:
https://github.com/sagesharp/outreachy-django-wagtail/blob/f8b0a66c1bf21cac8b53749f404095a9b782265b/outreachyhome/templates/base.html#L48

On the Outreachy homepage, we have our sponsor logos for the current round. Each logo should have additional padding around them, so that the logos aren't too close together.

The logos are implemented as a new Wagtail block here:
https://github.com/sagesharp/outreachy-django-wagtail/blob/e5ae07b527659664f4efccd7b3e27794ccaf7028/home/models.py#L27

We special case the handling of logo images in the Django home page template:
https://github.com/sagesharp/outreachy-django-wagtail/blob/e5ae07b527659664f4efccd7b3e27794ccaf7028/home/models.py#L27

I'm not experienced in HTML or CSS magic enough to figure out how to add padding. I would appreciate help with this task from people who are experienced in front-end web design.

When a coordinator indicates a Community will participate in a round, we need to be more explicit about intern funding.

• Add a description to the Participation view of all the different ways they can get funding for their interns. They could have the funds come from community budget. They could have a corporation sponsor an intern. Their parent software foundation or non-profit could sponsor an intern. A regular Outreachy sponsor company could earmark their funds for the community. Once a community has secured funding for one intern, additional interns can be funded out of the Outreachy general fund, but only for exceptional applicants.

• When adding a Participation and funding information, state that coordinators can come back and update this information if they find more funding or have more details on their sponsors.

• Add a class to track tentative sponsorship information. Organizers will add this information (and perhaps later coordinators?). Track:

  1. What is the sponsor name?
  2. What is the sponsorship dollar amount?
  3. Is the funding is secured or tentative?
  4. (Optional) Date by which you will have a decision on funding.
  5. Additional information organizers need coordinators to know about this sponsorship.

• Add a class to track past community credit. This should have a dollar amount (not an intern integer) and a Foriegn key to a Community. Rarely, Outreachy interns quit or fail at the mid-term or final review. When that happens, if the sponsor has already been invoiced, Outreachy indefinitely holds onto the funds for when that community next participates in Outreachy. Often when a mentor has a bad experience with an intern, the community won't participate for a couple rounds, so credits can be held for years.

• Display any credits for a community on the Participation view. Note that coordinators should include any credits in the number of interns they're funding to round up to the actual total of interns they'll accept.

• Add a text box for coordinators to give organizers information about tentative funding. Many coordinators need to wait until a specific date to hear back for the final budget numbers.

• Add a NullBoolean field that is a check box that says "I have secured a funding commitment for at least one Outreachy intern."

Organizers should get an email on server errors and crashes, perhaps using sentry.io

When a community that has participated in the past hasn't said whether they will be participating in the current round, we have a "Notify Me" button. This currently does nothing!

Create a new through-table with a one-to-one relationship between a Comrade and a Community. Make the "Notify Me" button create an account. Associate the Comrade with the Community. When a new Participation is added for that Community, send an automated email to the Comrades that have signed up. Maybe then delete the through table?

Co-mentor approved - only send on co-mentor creation, not on project creation - only send if the community is approved to participate

• Cc: Co-mentor
• To: Approved Mentors
• Subject: Mentor Approved - NAME
• action -> create gmail filter for mentors mailing list RIGHT NOW
• action -> link to project read-only page

For the approved co-mentor in an approved community:
To: subscribe email address for mentors mailing list
Subject: subscribe

The current Outreachy application system has both mentor and applicant sign up on the same page. The buttons are 'Apply to participate' and 'Apply to mentor'. Applicants often accidentally pick 'Apply to mentor', and we had mentors who have clicked 'Apply to participate'. We need to have completely separate login pages for mentors and applicants.

In the past, someone only committed the minified version of the bootstrap CSS to the older Outreachy website. Thus, we only have the minified CSS version committed: https://github.com/sagesharp/outreachy-django-wagtail/blob/master/outreachyhome/static/css/bootstrap.min.css

We need to unminify it, figure out which version of bootstrap was the original version, and what changes were made against that version. Then we can make those changes to a newer version of bootstap, and commit the unminified version.

Update dates for round 16 community onboarding:

• Start asking orgs on January 4
• Orgs need to tell us if they're participating by January 23
• Open applications February 15

There are several places scattered around the main website that reference round dates (e.g. some application step pages, the eligibility rules, etc). Those should be linked to the current round, and programatically generated from the dates in those pages. Ideally the sponsor page would reference when we need to know for sponsorship of the next round.

In Outreachy, we always need to have a "parent community" that is providing funding for each intern project. Examples of community and intern projects:

• Mozilla (community)

  • Lightbeam feature (project)
  • Rust feature (project)
  • Diversity research (project)
  • Usability testing for Firefox (project)

• Zulip (community)

  • Add new IRC gateway to Zulip (project)
  • Add support for adding new emoji to a Zulip community (project)

• Linux kernel (community)

  • work on graphics subsystem (project)
  • work on adding new Coccinelle scripts (project)
  • clean up Industrial I/O driver (project)

• GNOME (community)

  • Add feature to a GNOME module (e.g. Photo app, Files viewer, etc) (project)

All of these are examples of communities that participate in Outreachy. Some communities are a loose organization of "teams" of people, like how GNOME modules (applications) are associated with GNOME. Other communities, like the Linux kernel have a set of people who work on one or more subsystems that often are forced to cross-collaborate. Still other communities are tightly knit, like Zulip, where there is really only one "team" working on one piece of software.

The process of signing up a "project" needs to make it clear that all these scenarios can exist. Perhaps we need to use "Team" to reference the FOSS sub-community, and "project proposal" to reference the specific features the intern will be working on? The beta testers have been confused specifically about the longevity question for the Project class.

"Preview" is the magic word that means "don't share this page with applicants". Note who can view the preview, and that you should send applicants to the rounds page once the community is approved.

We'd like to be able to offer rich-text editing for some fields in Django forms. Django-CKEditor seems to have good repository activity, good documentation, and an intuitive editor interface.

We would use this for the longer community descriptions. (We don't want to allow links in the short description because we're trying to prevent applicants who aren't eligible from contacting mentors.) We could also use this in the application longer forms as well.

When a coordinator is on a Community read-only page, they can click the 'Coordinate for This Community' button, the form's post action redirects them to the community-coordinator-update view, with a coordinator_id set. However, if the user hasn't logged in yet, that id is set to None. When a coordinator follows the registration email link, they will fill out the Comrade information, and then be redirected to /communities/cfp//coordinator-update/None/ instead of using their new id.

New mentors shouldn't have this problem.

Once mentors see how their answers show up on the Project page, they may want to edit them. Have a "Edit Mentor Information" button on the project page. This might cause some confusion, since things like timezones are also "Mentor Information"? Perhaps we also need an "Edit Personal Information" button?

When a mentor selects their intern, they should immediately be prompted to sign the mentorship agreement. (This agreement needs to be executed each round, for each intern the mentor is mentoring.)

Right now, getting mentors to sign the mentor agreement is painful. Interns have incentive to sign the intern agreement, because they're told they won't get paid their initial stipend until they do.

Mentors have little incentive to sign the mentor agreement, because in their mind, they're done with the Outreachy application process once they select their intern. There's no consequence for them to not sign, so they are slow to sign. Mentors often have trouble even completing the application system sign-up process, since they aren't signed up as mentors before this (see #5). This causes additional manual labor by the Outreachy organizers.

Therefore, signing the mentor agreement should be done as the final step before mentors select an intern, when they still have incentive to complete the task.

It's confusing, and a beta tester said they didn't know what to put in it. Put the longer description after all the other fields.

Add a NullBoolean field to a Project. The NullBoolean is initially set to "None".

When a mentor submits a project (or updates a project) that uses a non-free license or proprietary software, set this bit to "False". Send an email to the Outreachy organizers with a link to the project page and description of which field was set. Have an approval button under Organizer Actions that can approve the project exception.

Only organizers should be able to modify this field. Even if the mentor edits the information later, the bit should remain set until an Organizer can review the project.

Currently warns the coordinator if the project longevity is less than 1 year. Should be six months.

Warns if the number of contributors on this team is 5 or less. Should warn if the number of contributors on this team is 2 or less.

Add CKEditorField for description of work to be done during the internship

Communication channels need to be separate classes with sub-classes for specific types of common communication channels:

1. Mailing list - URL for subscription page, email address, does the applicant need to be subscribed to send email, communication norms for the mailing list (e.g. where to check for the right person to send a question to; subject line suggestions)

2. IRC channel - host, port, channel, communication norms (e.g. how to find the right person to ask a question of, applicants shouldn't "ask to ask questions", wait for at least a day for your question to be answered and don't drop off the channel. The default should be basically everything on this page.

3. Zulip channel - URL, link to Zulip help documentation, communication norms including which channel to join after applicants sign in

4. Discourse forum - URL, link to Discourse help documentation, communication norms including URLs for which topic(s) to comment on after applicants sign in

5. MatterMost forum - URL, link to MatterMost help documentation, communication norms including who to ask questions and how to get help.

6. Other - URL to join the communication channel, does this require creating an account, URL for help documentation for this communication tool, communication norms.

One of the beta testers said they felt overwhelmed at the question to list organizations participating in their community. They have a community with many organizations, and they weren't sure if we wanted them to list all of them. Listing the "five main organizations" should probably be enough to prove that a community isn't controlled by one company alone.

Every round, we get many mentors who have never signed into the Outreachy application system, but they want to select an intern. This means we have to run them through the process of signing up in the application system, being manually approved by an Outreachy organizer, and then directing them to 'claim' their intern. This causes a lot of manual labor, at a time when organizer's time is very limited.

Additionally, sometimes community coordinators pick an intern without having a mentor committed. Outreachy organizers have no insight into when this occurs, because the current application system allows selecting an intern without having an assigned mentor. We need to be aware of this situation because it often impacts funding decisions. We should never accept an intern if we don't have a mentor for them.

The new application system should only allow an applicant to be selected as an intern by the mentor who is committed to mentoring that intern. Projects should only be displayed on the Outreachy website if they have an associated mentor.

Currently, the registration form (and possibly the login page?) requires a next page link (set in the URL like http://localhost:8000/register/?next=/ to bring the user back to the home page). That means if we link to the login page (rather than prompting the user to log in when they reach a page that requires user permissions) the site will throw an error.

Make sure that every code path handles the case of the next page is empty.

Don't allow them to sign up for a project unless they check all of the following buttons:

• "Instructions read"
• "Understands intern time commitment"
• "Understands applicant time commitment"
• "Understands mentor contract"

I have the webpages in markdown, so it should be easy for me to add everyone who offered internships in the past three years.

When a Community is approved by Outreachy Organizers, we need to let coordinators and mentors know what actions to take next.

To: Coordinators

• Subject: NAME approved to participate in Outreachy
• action -> create gmail filter for mentors mailing list RIGHT NOW
• action -> get mentors to add their projects
• action -> approve or reject pending projects (have a list)

For each approved coordinator:

• To: subscribe email address for mentors mailing list
  • Subject: subscribe
  • Body: subscribe "Name"

To: approved mentors with approved projects

• Subject: NAME approved to participate in Outreachy
• action -> create gmail filter for mentors mailing list RIGHT NOW
• (?) action -> if approved projects with mentors, link to community landing page, they can start advertising their community

For each approved mentor with an approved project:

• To: subscribe email address for mentors mailing list
  • Subject: subscribe
  • Body: subscribe "Name"

When a Project is approved by a FOSS community coordinator for an approved community, we need to let mentors know what actions to take next.

To: newly approved mentors in an approved community

• Subject: Project approved to participate in Outreachy
• action -> create gmail filter for mentors mailing list RIGHT NOW
• (?) action -> if approved projects with mentors, link to community landing page, they can start advertising their community

For each approved mentor in an approved community:

• To: subscribe email address for mentors mailing list
• Subject: subscribe

Instead of using absolute URLs in templates to point to wagtail pages like https://www.outreachy.org/apply/eligibility/ we can use relative URLs like /apply/eligibility/.

Wagtail might have a template tag that we can use to reference pages by name.

Once a new community or a past participating community is submitted to the Outreachy organizers for review, the next step is for coordinators to get mentors to submit project proposals. A beta tester got confused about what the next step was after they submitted a community.

Make that clear with an informational box at the top of the screen (if a community is pending or approved and no mentors have submitted a project). Make sure that the email to a coordinator when their community is approved has these instructions as well.

Coordinators and applicants need to know how the mentor is qualified to be a mentor for this project. (We won't use the word qualifications, since mentors with impostor syndrome are likely to think they aren't experienced enough when they are).

When a mentor submits a new project or a Comrade signs up to be a co-mentor, ask them:

1. "What contributions have you made to this team and the parent community? If none, what contributions have you made to other FOSS communities have you made or what skills have you learned that will be help you mentor this project?"
2. "What is your mentorship style? Do you prefer short daily standups, longer weekly reports, or informal progress reports? Are you willing to try pair programming when your intern gets stuck? Do you like talking over video chat or answering questions via email? Give the applicants a sense of what it will be like to work with you during the internship."

Display this information to coordinators who are approving mentors, on the project landing page, and on the project read-only page.

The design document for this task lives here. Any discussion of process flow changes, or new data to collect should be made as issue comments. Agreed upon changes should be committed to the design document.

A Comrade is the name for a person who has an account on the Outreachy site. (This isn't called a "user" because of the connotation that word has with people who have issues with addiction.)

Right now, we allow Comrades to pick up to four languages as part of user registration. Each language list is over 7,000 entries long. They aren't in alphabetical order. There are often local dialects that come before the more common language in the list. Picking a language is very hard, but we want to be inclusive towards people who speak less common languages.

The short term solution is to simply remove the languages dialogs from the views that create a new Comrade or update Comrade information.

Longer term, we should add JavaScript support for an empty text field box, which users can start typing in and it will display matches from the list, or allow them to input a custom language.

The community read-only page is very cluttered with coordinator actions they need to take. Have a separate page that lists actions they should take. Make the community read-only page have an informational box saying there are actions the coordinator needs to take.

When a new Project is created, coordinators should get an email that explains how they can approve it.

• Subject: Outreachy project proposal for COMMUNITY NAME
• To: Coordinators
• Cc: Organizers (only if there's organizer-level warnings about this project, e.g. license or proprietary software)
• list warnings
• action -> link to project read-only page, approve project

Currently, when you use the Wagtail "Header" block, there's nothing in the CSS to add formatting for it. It ends up as unformatted text.

Ideally we'd use the header block for adding an anchor tag to important sections. For example, on the mentors page we'd like to reference the list of mentor duties. Another example is on the mentor FAQ page where we'd like to reference the instructions on what makes a good Outreachy project.

This probably requires some Python code as well, to add anchors to the HTML.

Mentors should have a page to add a new skill, or move onto the next step. Clicking the 'Save Skills and Add New Skill' button should have any edited skills (add text to make sure mentors know this is the case) and then reload the page with a new blank skill. Clicking the 'Save and Continue' button moves to the next step.

Have a list of things that are default text, with links like "Fill out this field on the Project/Community Information page"

On desktop browsers, the Outreachy navigation bar now has enough menu items that it covers up the first sentence or two on the page.

At the minimum, we need to fix the bootstrap menu navigation bar CSS so that it's not hiding text. I think we need all the menu items, but I'm open to rearranging them into sub-menus if someone wants to propose a different ordering.

Ideally we'd also find a way to make it use the official Outreachy logo.

Depends on #12.

Only send this email if the newly created mentor has a pending approval. Mentors who have just submitted a project are automatically approved for their project. The thinking is that the first mentor is an all-or-nothing thing - either you want the project with its submitting mentor or you'll reject the project.

Note that we DON'T add approved mentors on the Cc here - because then a troll would know the coordinator's email address when they get the email.

• To: Coordinators
• Subject: Mentor approval needed - PUBLIC NAME
• list: warnings
• action -> link to project read-only page, approve mentor

Templates that display mentor, coordinator, or applicant pronouns should check pronoun permissions, and then display the pronouns with a link to pronoun.is for that pronoun.

We need to carefully check who is viewing this page. If the person has said public pronouns are ok, display it when people aren't logged in.

If a person has said they only want to reveal their pronouns to other Outreachy participants:

• Mentor - display the pronouns on the project page to the coordinator for their community and approved mentors for that project. Mentor pronouns on the landing pages should be visible to any eligible applicant.
• Coordinator - Pronouns on the community read-only page should be visible to approved mentors. Coordinator pronouns on the landing pages should be visible to any eligible applicant.
• Applicant - on applicant dashboard (TBD) show pronouns to coordinators and approved mentors for the projects they're applying for.

FIXME: not sure how to handle volunteers here?? Seems like we shouldn't trust them with being able to see applicant pronouns, even if they can review applications. Default to a smaller set of people who can see pronouns always when faced with this choice.

The RGSoC short code is too long - fix the model to accept a longer short code. This means mentors can't say they've been participating in RSoC before.

Change to make the coordinator assert that "All projects will be free and open source software and will forward free and open source software, not proprietary software".

Outreachy already has a planetaria at http://www.planeteria.info/outreach/. However, that has the following issues:

• Outreachy organizers need to manually add intern blogs and RSS feeds to the planetaria, and also to the Outreachy website. It makes no sense to manually add them in two places
• The planetaria is... fragile. Interns often try to hack together their own RSS feed generation, and sometimes that breaks planetaria, and the single maintainer is sometimes busy. Moving to a more widely used RSS toolset with more responsive maintainers would be good.
• The planetaria hosts both current intern blogs and alumni blogs. There's no way to filter to just the current interns, and the list of blogs in the right hand side is too long to easily scan. Having a way to filter for current interns, or all blogs for a particular Outreachy community would be good.
• The planetaria currently displays the full text of all blogs. This makes scanning for interesting topics hard. It would be good to (by default) collapse blog contents.
• Having the intern blogs hosted under the outreachy.org domain would aid search engine indexing.

This task has the following dependencies:

• We need to have a Django model for an intern, which includes their blog. This is the main gating task here, and it's something I want to define carefully.
• We need to have user accounts set up on the Django website, so that interns can edit their own blog and RSS URLs, so this eliminates the manual task of Outreachy organizers adding them.
• We need to set up a cron job on the Django server to pull down the contents of the intern blogs. There's probably good software for this already.
• We need to set up a Django package that takes the pulled down blogs, displays them in a page, and generates an RSS feed for that page.
• Bonus points if we can get different RSS feeds for different cohorts (rounds of interns) or all interns for a particular Outreachy community.

The flow currently takes you to the Coordinator personal information page. Instead it should take the coordinator to the community read-only page.

Hello, I'm unable to find the Mozilla option in the "Select organization" field.

We often have projects that are listed in both Google Summer of Code and Outreachy. Sometimes a project is only listed in Outreachy because of mentor preference.

When a project is listed in both Outreachy and GSoC, we can increase the chances of an applicant getting accepted by encouraging them to apply to GSoC. Outreachy has a limited amount of funds, and if the intern is willing to accept a pay cut (depending on which part of the world they live in) then it's beneficial for them to apply to both programs.

GSoC will announce accepted communities on February 12. On that date, we want to email all mentors from a community participating in GSoC and ask them to mark their project as participating in GSoC or not. Ideally this button would be hidden from the project page until the day they receive confirmation that their community is accepted into GSoC.

1. Add a new NullBoolean field to the Project class. "None" means a mentor hasn't said whether this project is participating in GSoC. "True" means the project is participating in GSoC. "False" means it's not participating in GSoC.

2. On the project landing page, add information about the project participating in GSoC. Link to GSoC application instructions. Warn applicants about the pay decrease, and link to GSoC's list of payment amounts per country. Tell them they will increase their chances of getting accepted if they are willing to take less of a stipend.

3. Once a mentor indicates that their project is participating in GSoC, email all applicants who have submitted an application to tell them they can apply to GSoC (ideally with the same text as what we put on the project page). This last step will need to be implemented after we get the new application system in place.

Need to have a test server managed by dokku at test.outreachy.org. Currently we're just crossing our fingers and pushing to production after local testing. 😱

Ideally in the future we would set up a test server for each developer to push to. We need to have a way to copy the Django database, scrub any personal data (like email addresses). We could use Django fixtures to define the models we want to test.

If a Comrade tries to take a "rare action" that could negatively impact someone, we should have a separate confirmation page that displays what the action will do and has Confirm and Cancel buttons.

Organizer (staff) rare actions include:

• rejecting a community

Coordinator rare actions include:

• rejecting a mentor
• rejecting a project
• withdrawing from the round
• withdrawing as a mentor

Mentor rare actions include:

• withdrawing as a mentor
• withdrawing their project