Public Lab has received support for fellows to work on Public Lab software projects via several "Summer of Code" style programs including [Google's Summer of Code program](https://summerofcode.withgoogle.com) -- 2021 is our eighth great year of open-source coding with GSoC! In 2017 and 2018 we also joined the [Rails Girls Summer of Code](https://railsgirlssummerofcode.org/) program, and in 2018 we participated in [Outreachy](https://outreachy.org). This is a key way that we are able to develop our collaborative platform (this website) as well as [other Public Lab coding projects](/developers). > We especially welcome contributions from people from groups underrepresented in free and open source software! ## How to apply Want to get involved? As a first step, **we ask everyone to complete a “first-timers-only” issue**, which you can find on our Welcome page at https://code.publiclab.org. While it’s helpful to have some experience with the Git version tracking system, we have [guides to help you go through this process](/developers#Resources), and will be there to help you get your code posted. Almost all of our code is in Ruby on Rails and JavaScript, so basic familiarity with these systems is a plus. We have a chatroom at https://publiclab.org/chat where you can get help pretty much any time. **** ### Project ideas We kick off each season with a big brainstorm of ideas. You can find this year's discussion here: (Coming soon!) Last years can be found here: https://github.com/publiclab/plots2/issues/7360 Our [Summer of Code Ideas Page](/gsoc-ideas) will list the **final brainstormed ideas** that come out of this process. **** ### Call for proposals We have not yet opened our call for proposals, but [you can read last year's here](https://github.com/publiclab/plots2/issues/6285), to get ready! Feel free to ask questions there as well until the 2020 call is posted. Thanks! You can see past years' calls for proposals lists here: https://publiclab.org/tag/call-for-proposals The call for proposals asks people to post their proposals using this template: https://publiclab.org/gsoc-application-template We encourage people to leave comments, encouragement, tips, and questions on each others' proposals in a community fashion, and to be **friendly and welcoming** to one another! **** ## How we work Over recent years, we’ve steadily refined a workflow that helps new contributors get plugged into our community and code with a warm welcome, and aims to support building skills incrementally and cooperatively. We’re always looking for ways to improve, and welcome feedback! Once you are comfortable with our workflow by completing a `first-timers-only` issue (see above) we’d like to ask that you compile your project steps into a planning issue, which [you can learn about here](/notes/warren/01-18-2018/software-outreach-modularity-is-great-for-collaboration). You can see examples here: https://github.com/publiclab/plots2/labels/planning At this point, we recommend you begin going through the task list, creating a pull request like a mini-project for each task. Each one will ideally have tests, and we can help you develop these. As you progress, we encourage contributors to grow as leaders by reviewing others’ pull requests, helping troubleshoot, and also taking small parts of your project to post as “first-timers-issues” for someone else. You can read more about these steps at https://publiclab.org/software-outreach and https://github.com/publiclab/plots2/labels/support. Your code will be reviewed, supported and troubleshooted (troubleshot?) and potentially published to our live site as often as once a week, and you’ll be able to see it running and get feedback from people about it to inform your work. Towards the end of your project, we’ll encourage you to take remaining pieces you’d like to see followed-up on in the future, and describe them with enough information for others to take up and complete. This could be in the form of “first-timers-only” issues, or “break-me-up” issues that list out steps that can be adapted into small stand-alone tasks. ### What makes a good project Hi all, at Public Lab, @emash and @warren brainstormed on this a bit, and we felt that a good project: - can be broken into smaller parts that can be merged into our main branch on at least a weekly basis - could be completed as a "small" initial version (MVP) that is later expanded on or refined - has an integrated recruitment plan, i.e. the student has plans to recruit others into the project and designs the project for this - has background/context/historic info readily available to inform the work - is generally self contained - all the code in one place (or clear integration guidelines provided) - contributes to our software roadmap - (stability, maintainability, low technical debt, legible: https://publiclab.org/notes/warren/05-22-2019/draft-of-a-public-lab-software-roadmap-comments-welcome) - solves priority issues for Public Lab's broader community - provides a feeling of accomplishment! - helps students build skills/portfolio - is a "cool new thing" (but not all the projects we NEED done fulfill this...!) - has a good plan for integration/publication to the live production environment, and schedules time for this ### Evaluations We've posted various guidance on how we do evaluations in our Summer of Code programs. Here is a short collection of suggestions and info! * https://github.com/publiclab/plots2/issues/5930 * https://publiclab.org/notes/warren/08-20-2019/wrapping-up-outreachy-and-gsoc-2019 ## Using Milestones and Planning issues You have been selected for the Summer of Code Program, congratulations! The first thing you should think about in your first week is breaking down your projects into small chunks. Use this link as a resource on how to break down the tasks needed for your project https://publiclab.org/notes/warren/01-18-2018/software-outreach-modularity-is-great-for-collaboration Once you have broken down your tasks, the next thing to do is create an issue to list all the tasks needed for your project. You could use a format similar to these issues: * https://github.com/publiclab/plots2/issues/8513 * https://github.com/publiclab/plots2/issues/9069 Using the checklists and creating an issue for each task before the implementation period helps the mentors know what is expected and they can also help you break down or modify the tasks. Please also note that the tasks do get updated, modified, or added throughout the project, you need to be flexible and adaptable to that. Also, we encourage you to create a milestone that will track the progress of your completed task. Once a task is completed and marked as done on the issue checklist, or an issue /PR has been closed or merged add it to the milestone. Have a look at this link to learn more about milestones: https://docs.github.com/en/github/managing-your-work-on-github/tracking-the-progress-of-your-work-with-milestones/about-milestones You are always welcome to reach out and ask any questions **** # Questions [questions:soc] ## Activities [activities:soc] **** ### Mentoring What does it mean to be a mentor? Mentors **check in with a student at least once per week** roughly from May-August, and offer some project management guidance and encouragement... while relying on the [plots-dev list](/wiki/developers) and the `@publiclab/reviewers` group on GitHub to provide code-specific input, so that we share the burden of specific technical support. This means that **to be a mentor you don't necessarily need to know how to code** -- we need mentors who know Public Lab's community and practices well, and who can encourage students to speak up when they get stuck, and to ask the community for input and testing of their work. Students often get stuck when they don't know how something should look, or how a feature might be used by the community -- contextual info! If you're interested in being a mentor, email the developers list or jeff@publiclab.org -- and read over our [software outreach resources](/software-outreach) to get an idea of how we work! Some more resources on mentoring: * our [Summer of Code workflow](https://opensource.googleblog.com/2016/12/google-summer-of-code-2016-wrap-up_21.html) * read [different ways to mentor in this post](/notes/warren/11-08-2016/help-public-lab-s-software-grow-by-joining-a-supportive-team) -- we need various types! * read about [what reviewers do day-to-day on Public Lab code projects](/wiki/developers#Reviewers) * read about [our commitment to modularity](/notes/warren/01-18-2018/software-outreach-modularity-is-great-for-collaboration), very important in how we ask contributors to work * read over our [software outreach strategies](/software-outreach) * http://write.flossmanuals.net/gsoc-mentoring/ also has a lot of resources on mentoring, though not specific to Public Lab **** ### Communication We do occasional chat or video sessions, and mentors rely on each other quite a bit, in [the chatroom](/chat) and [on the plots-gsoc list](/developers). ### Benefits Our code contributor community is built on a commitment to mutual benefit -- we can’t create good software without welcoming in newcomers, and we are deeply invested in supporting contributors to learn new skills and grow as coders, designers, project leaders, and “cooperators”. Unlike many open source communities, much of our capacity is aimed at helping people become proficient coders, and to learn and apply principles such as code modularity, test-driven development, and more, as outlined at https://publiclab.org/software-outreach. But we also seek to change coding culture by recognizing how important communication, mutual support, and affirmative and welcoming tone are. As part of this, we seek to improve ourselves and help contributors learn how to support one another, welcome in a diverse and inclusive community, and build a more positive and equitable society by doing things a little differently. **** ### Past years * 2019: #soc-2019 #outreachy-2019 * 2018: #soc-2018 #outreachy-2018 * Starting in 2017, we began using tags to organize content, such as #soc-2017 * [Call for proposals](/notes/warren/02-28-2017/call-for-proposals) and [wrap-up](/notes/warren/09-07-2017/wrapping-up-google-summer-of-code-2017-at-public-lab) * [GSOC 2016](/wiki/gsoc-2016) program, projects, students and mentors * [GSOC 2015](/wiki/gsoc-2015) program (application only), projects, students and mentors * [GSoC 2014](/wiki/gsoc-2014) program, projects, students and mentors * [GSoC 2013](/wiki/gsoc-2013) program * [GSoC 2013 mentors & proposals](http://publiclab.org/wiki/gsoc-2013-mentors-and-student-proposals) **** ### Updates [notes:soc] ...
Author | Comment | Last activity | Moderation | ||
---|---|---|---|---|---|
cfastie | "Any workflow will be great. The workflow that I imagine is usually not the one that is available. That is probably good for the rest of the world. ..." | Read more » | almost 10 years ago | |||
warren | "It sort of re-orders things to be able to upload an image before defining a map to upload it to, but I think we could do some trickery to have it c..." | Read more » | almost 10 years ago | |||
warren | "Ah, you do have to create a map first. Then you can start dragging in images. Do you think that could be more clear? " | Read more » | almost 10 years ago | |||
cfastie | "I was very excited to try this, but MapKnitter gave an error because I did not enter a lat and lon for the map. That seemed to defeat the purpose. " | Read more » | almost 10 years ago | |||
navonod | "Follow-up: I was able to solve the first problem by allowing the framework to instantiate the icon for me - i.e. only worrying about creating a L...." | Read more » | almost 10 years ago | |||
navonod | "@justin - Many thanks for the great efforts you made in getting leaflet.illustrate to this point. I have 2 implementation questions, if you don't m..." | Read more » | almost 10 years ago | |||
patcoyle | "Jeff, Nice quick walk through video. Thanks again to the whole team. " | Read more » | almost 10 years ago | |||
justinmanley | "Yup, I suppose that's necessary. Shouldn't be too expensive to run a separate Amazon RDS database just for the duration of testing. I agree that ..." | Read more » | about 10 years ago | |||
warren | "Justin - when you suggest running it on test.publiclab, you mean with its own database, right? " | Read more » | about 10 years ago | |||
justinmanley | "@warren - nope. The database is pretty much the same, but I significantly changed the route mapping in order to take advantage of the resourceful ..." | Read more » | about 10 years ago | |||
anishshah101 | "Hi, There are 2 things which will be a problem while trying to convert the CSS transform into Javascript: 1) The CSS 3D transform used here: http..." | Read more » | about 10 years ago | |||
warren | "Justin, is the annotation tool at a unique /map/annotate/foo route, so that we could roll out your code and keep the branches closer aligned, even ..." | Read more » | about 10 years ago | |||
warren | "I'm currently reworking Anish's work, so that's good that you've done more on Vidun's. https://github.com/publiclab/ImageDistortLeaflet I'd like ..." | Read more » | about 10 years ago | |||
justinmanley | "Jeff - It's awesome that you ported MapKnitter to Rails 3! Like, so awesome. FYI the annotation branch isn't ready for production or even beta us..." | Read more » | about 10 years ago | |||
mihow | "Hi @ives, the GPS Test app is even better! Thanks for the tip. Unfortunately though, the SkyCam app is not working well on my phone. It does not s..." | Read more » | about 10 years ago | |||
warren | "Ported to Rails 3! https://github.com/publiclab/mapknitter/tree/rails3 I'm getting your annotation branch and attempting a merge in and thorough c..." | Read more » | about 10 years ago | |||
ives | "Hi @mihow, I figure this out through a different App, named "GPS Test". Looks like both Google Maps and GPS Test "warm up" the location, and then S..." | Read more » | about 10 years ago | |||
mihow | "Hi @mercyorangi thanks for your great work on this app! I have it installed on my HTC One S that is running Android 4.3.1 I see there have been so..." | Read more » | about 10 years ago | |||
ives | "Hi @mercyorangi! You are doing an excellent work on the app! :) I was trying it on my MOTO X (1st model), and realize that the pictures wasn't sen..." | Read more » | about 10 years ago | |||
liz | "hey @justinmanley , thanks for making mapknitter so much more awesome! These ideas are really cool. Everyone's looking forward to them. " | Read more » | over 10 years ago | |||
justinmanley | "Ahh. I see what you mean about the date the images were taken being different from the date the map was made. I think that for the time being, it..." | Read more » | over 10 years ago | |||
liz | "interesting @justinmanley . I often make maps of the same site over time, and I like the titles to be crystal clear. Sometimes i search by date and..." | Read more » | over 10 years ago | |||
justinmanley | "Hi all - thanks for the feedback. I have added most of the bugs your reported to my todo list on GitHub. I'm working hard on integrating annotati..." | Read more » | over 10 years ago | |||
mathew | "I know I should put these in as Github issues, but here are my notes on first use, before I head out to lunch: I logged in before creating a map b..." | Read more » | over 10 years ago |