outreachy / website Goto Github PK
View Code? Open in Web Editor NEWCode for the Outreachy website, based on Python, Django, and Bootstrap.
Home Page: https://www.outreachy.org
License: GNU General Public License v3.0
Code for the Outreachy website, based on Python, Django, and Bootstrap.
Home Page: https://www.outreachy.org
License: GNU General Public License v3.0
Outreachy is a volunteer organization under the Software Freedom Conservancy that provides internships and mentoring in Free and Open Source Software (FOSS). Outreachy coordination tasks include promotion, herding project mentors, and a whole lot of data wrangling. This repository includes scripts I create to help me with those tasks, updated artwork for promoting Outreachy, and anything that's public and needs to be under revision control.
Communication channels need to be separate classes with sub-classes for specific types of common communication channels:
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)
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.
Zulip channel - URL, link to Zulip help documentation, communication norms including which channel to join after applicants sign in
Discourse forum - URL, link to Discourse help documentation, communication norms including URLs for which topic(s) to comment on after applicants sign in
MatterMost forum - URL, link to MatterMost help documentation, communication norms including who to ask questions and how to get help.
Other - URL to join the communication channel, does this require creating an account, URL for help documentation for this communication tool, communication norms.
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.
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.
Outreachy already has a planetaria at http://www.planeteria.info/outreach/. However, that has the following issues:
This task has the following dependencies:
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.
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:
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."
Update dates for round 16 community onboarding:
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.
Co-mentor approved - only send on co-mentor creation, not on project creation - only send if the community is approved to participate
For the approved co-mentor in an approved community:
To: subscribe email address for mentors mailing list
Subject: subscribe
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.
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.
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.
Organizers should get an email on server errors and crashes, perhaps using sentry.io
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.
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.
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.
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.
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:
Display this information to coordinators who are approving mentors, on the project landing page, and on the project read-only page.
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.
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.
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.
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.
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.
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.
Have a list of things that are default text, with links like "Fill out this field on the Project/Community Information page"
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".
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.
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 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
For each approved mentor in an approved community:
"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.
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?
Add to top of view template.
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:
Coordinator rare actions include:
Mentor rare actions include:
Add CKEditorField for description of work to be done during the internship
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)
Zulip (community)
Linux kernel (community)
GNOME (community)
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.
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.
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:
I think it could be fixed here:
https://github.com/sagesharp/outreachy-django-wagtail/blob/f8b0a66c1bf21cac8b53749f404095a9b782265b/outreachyhome/templates/base.html#L48
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.
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.
When a Community is approved by Outreachy Organizers, we need to let coordinators and mentors know what actions to take next.
To: Coordinators
For each approved coordinator:
To: approved mentors with approved projects
For each approved mentor with an approved project:
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.
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?
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:
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.
When a new Project is created, coordinators should get an email that explains how they can approve it.
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.
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.
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.
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.
Don't allow them to sign up for a project unless they check all of the following buttons:
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.
The flow currently takes you to the Coordinator personal information page. Instead it should take the coordinator to the community read-only page.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.