This is a proposed project for Outreachy. Note that once this ticket is approved you will have to register as a mentor on the Outreachy page and enter this information again. Many of these questions are based on the application on the Outreachy website.
One-line name Fedora Websites Longer description of project We are looking to migrate our various sub-domain websites into the common getfedora.org umbrella. This includes migrating content from labs.fedoraproject.org, spins.fedoraproject.org, alt.fedoraproject.org, iot.fedoraproject.org, and several others, to be simple pages on getfedora.org, so that getfedora.org is the single place to… get Fedora. It also means updating some independent sites to from the old framework to Flask. License of the project No LICENSE file in the repo, so defaults to the default Fedora license under FPCA which is MIT. Longevity (How long has the team accepted contributions) Years and years, but the new getfedora only went live last year and has accepted contributions from the start. Community size The entire Fedora community, but there are currently 17 unique contributors to the getfedora.org repository, as per `git shortlog -ns | wc -l` How will this project benefit Fedora Our websites ecosystem is fragmented and finding the right download can be painful if you don’t know where to look. Having everything under the common “getfedora” umbrella creates a simpler user experience which benefits Fedora by attracting more users to the various versions of Fedora, easing support (by having less people ask where to find a particular download), and making it easier for developers (by having one common place to update to point to a particular release, versus having to find the appropriate website(s) and update them accordingly). Sample plan of work for the 12 week internship. What are milestones the intern should be hitting? This doesn't need to be incredibly detailed and can change later but there needs to be a general breakdown of tasks. The milestones can be broken down into individual sites. So the first milestone, for example, could be “migrate spins.fedoraproject.org to getfedora.org/spins”. WIthin this, there are subtasks...For example, “Migrate the KDE spin.” Here is an example schedule, but it absolutely will change: Week 1-2: Onboarding, getting a dev environment set up, learning the ropes, simple changes just to learn the process Week 3-4: Port spins.fedoraproject.org and iterate on it, and learn how to send strings to translators Week 4-5: Port labs.fedoraproject.org and iterate on it Week 6-7: Port arm.fedoraproject.org and iterate on it Week 8-9: Port alt.fedoraproject.org and iterate on it Week 10-11: Port flocktofedora to separate Flask site Week 12: Wrap-up and reflect Benefits to intern (What will the intern get out of this internship) The intern will get to have their work realized on the public facing landing page of a large open source project. They will also get to work with talented designers and engineers who are also volunteering their time on the Fedora Websites team. They’ll get to learn how the Fedora websites are built and translate this knowledge into their future work. Project website https://getfedora.org/ Project repo New: https://pagure.io/fedora-web/websites/ Old: https://pagure.io/fedora-websites Where can an applicant find application tasks? To be determined. There are issue trackers on both repositories, and after the project is accepted, I can create specific issues for the work required with a breakdown. This doesn’t currently exist. IRC Freenode, #fedora-websites Skills required including what level and if they are optional Significant HTML and CSS (particularly Bootstrap) and Git experience required. Previous Python experience will be useful but isn’t strictly required (we use frozen-flask as our website generation system). Knowledge of IRC communication is helpful. Excellent communication skills and working knowledge of English for communication on tickets, mailing lists, and IRC. Previous experience working on a small team in a software development environment will be useful but not required. (Bonus points for previous open source work). Outreachy applicants are required to make a contribution as part of the application. What is the process for making a contribution?] Fork the repository on Pagure Establish an understanding of the requirements Write the code and push it to their fork Send a pull request Iterate on pull request with feedback from mentor and other community members After pull request is accepted, update documentation (separate repository) as necessary, by following a similar process (fork, pull-request).
Questions from the top level Outreachy Program for the mentor application:
How long have you been contributing to the community
A decade. And now I feel old.
What is your current role
Sysadmin, application developer, infrastructure authentication guru, pseudo web lead
Have you mentored for a three-month internship program before
No.
Have you read the mentor page and understand the process of being a mentor
I have skimmed it and will read it more closely soon.
Are you available for 5 hours a week during the internship period
Yes, but not necessarily in US working hours.
Are you available for 5-10 hours a week during the application period
Yes. Same as above.
Are you aware you need to sign a mentor contract
Yes.
Metadata Update from @siddharthvipul1: - Issue tagged with: Outreachy
@labbott and @riecatnor
Metadata Update from @codeblock: - Issue untagged with: Outreachy
Metadata Update from @codeblock: - Issue tagged with: Outreachy
"To be determined. There are issue trackers on both repositories, and after the project is accepted, I can create specific issues for the work required with a breakdown. This doesn’t currently exist."
I'd like to see application tasks before we accept this project. It makes it much easier to know what the applicants should expect.
@codeblock can you break down the tasks a little bit more? I don't think it needs to be entirely broke down into steps, but a couple major tasks outline will help here. Thanks!
@codeblock heya! Checking in here, as the project proposal deadline is coming up quick. Thanks :)
@riecatnor I'm not entirely sure what the ask is here. You just want to see tickets for the large items? https://pagure.io/fedora-web/websites/issues?status=Open&tags=outreachy
In the interest of time, I haven't filled in descriptions for now, but they at least mention the sites that need to be ported. I don't think there's enough time to outline a step-by-step for these before the deadline, but I will have something by the time the intern starts.
hiya @codeblock upon reading a bit further, it looks like @labbott is looking for specific application tasks. With Outreachy the potential interns will need to do application tasks for about a month before someone is selected. Once the project proposal goes public(March 5th), it would be advantageous to have specific tasks set out for that beforehand (basically you can have 5-15 people show up over night looking for tasks). Does this help to clarify?
https://www.outreachy.org/communities/cfp/#mentor The timeline we are working with is the project proposal needs to be submitted by you on Outreachys website by February 27th at 4PM UTC. Small alterations can be made if needed beyond that point. The application period for the interns begins March 5th.
@riecatnor that clarification helps a ton, thank you! Do I need different tasks for each applicant? Or is the goal to have them do the same tasks and see who does it best? Pending your answer, I will write some up tomorrow!
@codeblock A mix of both is a good idea. I left some suggestions in #68 from past internships that you might find helpful too:
https://pagure.io/mentored-projects/issue/68#comment-621891
Okay, how about this for starters:
That's a very good set of first instructions. What are you thinking about for applicants to submit so you can review and decide which applicant you want to accept?
We could use one of the simpler sites (maybe arm or alt) and have people try to port it and see how far they get (have everyone do the same one, so we can compare work fairly). This would show that they are capable of making pages on the new site, they have an understanding of what we're trying to do, they know enough design to at least get a simpler one done. This will give us a lot to go by: How far did they get? Does their code follow the same style as code nearby it? Were they able to get set up at all? Can they use git sanely?
In the beginning I expect people to ask a lot of questions, so the kinds of questions they ask and the way they engage with the community and others in the channel will play a role as well.
Can you break down "have people try to port it" into smaller steps and put them in the issue tracker tagged outreachy or first issue? From past experience, the smaller tasks you can give people the better.
@labbott It's hard to break it into ticketable chunks really. I promise I'm not trying to be difficult and I'm very open to suggestions here.
"Porting arm.fp.o" is basically "Add a line to a python file, then work on copying content over using the existing pages as a guide for how we use Bootstrap, etc." with a side of "Let's pull out things like version numbers to YAML files because manually editing templates for a release is painful."
I'm not sure how to break that up into tickets without being like "draw a circle, then just draw the rest of the owl".
That all sounds like what you should put in the ticket. It's okay if it isn't super specified but writing "1) add X to file Y 2) copy content over following Z as a guide" is at least enough to get an applicant started.
@codeblock I think this a better start, and also I would encourage you to keep working up the onboarding/application tasks. I don' t think each step needs it's own tickets. Maybe all of i can go into one to start, and bigger tasks can be broken off as things develop.
That being said, today is the deadline. I have been asked by the Outreachy organizers to get our project proposals in asap. If we need to make adjustments to it, we can. Please get it in ASAP. Thanks!
@codeblock I actually just checked the page, and it says the submission deadline has passed. I am emailing the coordinators now to see if we can slip this one through.
@codeblock @labbott this was successfully submitted and accepted!
Metadata Update from @riecatnor: - Issue status updated to: Closed (was: Open)