Plots2: Weekly Community Check-In #24 (Learning from Public Lab)

Created on 3 Jun 2019  ·  41Comments  ·  Source: publiclab/plots2

Hi everybody :smiley: !

We all at Public Lab :balloon: - learn, grow, work, brainstorm ideas, contribute together so why not share about our _weekly goals and the awesome work_ we have done at Public Lab with each other, so we can support and collaborate with each other better. We have a Community Check-In each week, where every community member can share something about their work from the past week and about their current week's goal :dart: . You are also welcome to share fun-fact :smile: , new ideas :bulb: , your learning goals :ballot_box_with_check: .

We believe in collaborative efforts to support our community. We are running a learning platform which helps a newcomer to become master of tomorrow. :100:

If you're new here, welcome, and please comment a _Hello_ below, we would love to work with you. If you're looking for new issues, please try some of our first-timers-only issues.

We're SO EXCITED to have your help!

Is there anything, you would like to share with us from past week's work? What is your plan for this week?

If you have not planned yet, just leave a Hello! :wave: so that we know that you are in sync with us :arrows_clockwise: and doing well!

The coming weeks will be full of code :computer: , tasks :spiral_notepad:, fun :tada: and excitement :smiley:!!

As always, if you're waiting for a review, or if you're stuck, please request help here OR leave a comment with @publiclab/mentors @publiclab/reviewers for some input. :raised_hands:

Gitter

Gitter is an active chatroom in our community and we'll be sending weekly reminders about check-ins there. Be sure to sign up there for these updates or just to join the conversation. You can also join us through http://publiclab.org/chat :speech_balloon:.

This Week's Theme - Something that you learnt by contributing to public labs !

This weeks theme is to share something that you learnt by contributing to the public labs community. It does not have to be technical(it can be). You could have learnt how to interact with people or how to politely point out mistakes while being kind(reviewing PRs). You could have learnt a new technology or skill. Maybe you gained communication and networking skills ! :tada:
Come on, list out your biggest takeaway from the amazing community of public labs :heart:

Keep contributing and keep challenging yourself :D

Alt Text

Welcome new contributors!
I would encourage new contributors to try different kinds of FTOs and help-wanted issues. Since open source is all about community and helping others, let's find some issues which might be good for someone else who is contributing or just beginning and help them solve it. Let’s expand our community as much as we can! :tada:

You can find our list of previous check-ins here

Note to Summer of Code interns:

Hi, we request all the SoC students to include the below-mentioned points in their check-in comment:

  • FTOs created in the previous week
  • Progress for your project
  • Upcoming week's goals
  • PR reviewed by you in the previous week
  • Work completed last week.
  • What things you did collaboratively last week? This is really important we want team spirit.
    It is like a weekly scrum. Be flexible.
  • Feel free to tell us about your absence too, if you're taking a break.
  • Issue/PR you're struggling with (if any)

With FTOs and PR reviews, we are seeking to develop a much more friendly and collaborative platform. We want you all will involve people in your project. You all will develop skills like leadership along the way.

Thank you!

community check-in outreach
Source
picture asquare14
❤7 🎉7 🚀6

Most helpful comment

Hi, everyone - i just submitted initial feedback from mentors for our Outreachy fellows. Congratulations!

I wanted to share that I wrote this blog post a few years ago after our first really big summer of code, and some of the "lessons we learned" we are still learning :-)

https://opensource.googleblog.com/2016/12/google-summer-of-code-2016-wrap-up_21.html

Below is the original draft which is a bit longer and written more directly for fellows and mentors, which you might find interesting. I may post a link in the Weekly Check-In as well.

(written in 2016) I just wanted to say that, although we’ve has some amazing summers in the past, this summer was once again our most successful summer yet. I think our continuous refinement of the planning process and how we run our unique Summer of Code process has really grown and allowed us to have:

  • More projects succeeding
  • More and better documentation
  • Clearer onramps for new contributors written by students who can build out their own contributor mini-communities over the summer
  • Better constant communication and inter-student collaboration
  • More modular, easy-to-integrate projects
  • More tests
  • Better work plans
  • An earlier, faster start to the summer

You can read more of the specific highlights of our projects on the most recent Web Working Group update. But I wanted to share some of the reflections, advice, thoughts, and ideas I’ve had over the course of this unique summer. I wrote some of this into each of your evals, but without sharing feedback specific to a given student, I wanted to share my notes. Apologies to non-coders if they’re very software-oriented, but I think some of these apply to non-coding projects too!

Turn your remaining work into well-documented onramps for new contributors

To students who are approaching the end of their projects, an important step is re-assessing what's left, and what they can finish up in the remaining time. But rather than considering any unfinished pieces "missing", it’s great to take them as an opportunity to invite others into your projects, by turning them into well-documented issues on your project repositories.

If you offer enough context, you should be able to recruit people to take up the remaining tasks once the summer ends, and whether or not you continue work afterwards, folks will be able to carry your work forward. This may mean writing a first-timers-only issue, for example, to welcome a new coder into the project.

Mentors: I think it's great to encourage students to document their work (and what's left to do) as issues that are up for grabs. It's better for morale to plan ahead for other people to pick up where you left off, and to think about your project living on, than to focus on asking them what they didn’t do! And it’s better for the project overall anyways!

Write issues for yourself, but as if written for others

Ask students to write one new issue per week for someone else, which helps them think in terms of how others read their work, and encourages them to break up projects into smaller parts that newcomers can tackle. Good code is modular, not a spaghetti -- and looking at it from the outside is a powerful way to improve your planning and style.

Learn how to develop a small community of contributors around your work

Over the course of your work, you've all become leaders in this community through your work, your collaboration, and your major contribution to the platforms we use at Public Lab. Take a look at this page for some ideas on how you can ensure your projects live on: https://github.com/publiclab/plots2/projects/4

Write onboarding or “first-timers-only” issues

I think asking or even requiring projects to have "onboarding" or "first-timers-only" tasks during the recruitment phase can help improve the overall success of the project and ensure project teams are giving students the support they need early on. This also helps ensure that students have installed everything and gone through the “PR merging” process before they even begin work!

Learn how to write a good, step-by-step first-timer issue

Start your summer by thinking about building a team by inviting others into your work. It’s a key skill for any software developer, and it’s never too early to think about documentation, or about designing for reuse and for other coders to read your work. As someone who’s probably just gotten the project installed and set up, you’re also uniquely equipped to guide others through that process! And it’s a good habit both for yourself (to break down and articulate problems in writing) and for future coders. Here’s a guide to writing issues for newcomers:

https://publiclab.org/notes/warren/10-31-2016/create-a-welcoming-first-timers-only-issue-to-invite-new-software-contributors

See your own work through others’ eyes

Towards the end of the summer, begin to consider how other people (who program) will use your work. Will they understand how to install it? How to adapt it to their own uses? Will they have trouble setting it up, or be confused at how things are named or organized? What can you do to make it easier for others to pick up your work and use it? A good demo? More clear documentation or examples? One great way to know if your work is readable is to ask one another to read it over and provide feedback.

Break your work into small parts!

Students love to make giant projects that are all intertwined, and it takes discipline to break things into small, testable parts. But be hard on the students early on -- resist the temptation to just say “code the whole thing up as fast as you can!” since it can really be worth the time to work with them to plan out and break down their work. It’s much easier to build on smaller self-contained modules that are clearly tested than to sift through huge amounts of less structured code, whether it’s the students themselves doing it or you taking over at the end of the summer. It’s also just good coding practice!

Write a planning checklist that you can work on chunk by chunk

Write a planning issue early on, based on your proposal. Take the overall goals and break them into parts small enough that you can merge them (with tests) into the trunk branch one at a time. Before a user-facing feature goes live, you can merge in a whole set of back-end functions which underpin it, and ensure they are all working in production before making the UI that exposes it to the public.

Break things into a checklist with "phases" and really modularize down into distinct steps as much as possible, like in this example:

https://github.com/publiclab/leaflet-blurred-location/issues/1

It's a really great way to visualize your progress over the course of the summer, and a good first step to developing a milestones.

Publish “hidden betas” to test your work in production

When students want to publish a public-facing interface (a new feature) but you’re not sure it’s perfect yet, allow them to publish it in a way that’s hidden, so you can see how it does “in the wild.” For web projects, only enable it if people add a ?beta=true parameter to the URL. For desktop projects, hide it behind a flag, like --enable-beta-features. That way, they can break up the work into smaller parts, and can get feedback from the real community as they refine their work. Just be sure the flags are clearly marked and can be removed by another contributor later.

Do you have more to suggest? I’d love to hear your tips -- leave them below in the comments.

Some of these you already know. But perhaps some may also help you chart and adjust your course now that you have a few weeks of work behind you!

Thanks everyone! 🎉 🙌

picture jywarren on 8 Jun 2019
❤8 👍6 🎉3 👎2

All 41 comments

@mohitRJranjan @milaaraujo @kevinzluo @Rishabh570 @sashadev-sky @shubhscoder @sidntrivedi012 @SidharthBansal @cesswairimu @stefannibrasil @ViditChitkara @tech4GT @mridulnagpal @IshaGupta18 @CoderJolly @namangupta01 @sagarpreet-chadha @Souravirus @MayankKashyap @siaw23 @ryzokuken @icarito @steviepubliclab, @ebarry, @jywarren, @sagarpreet-chadha, @JonathanXu1, @uzorjchibuzor, @eli6, @rexagod, @divyabaid16, @dinaelhanan, @oorjitchowdhary, @wanzulfikri, @mohitRJranjan @publiclab/mentors @publiclab/image-sequencer-guides @publiclab/leaflet-environmental-layers-guides @Paarmita @publiclab/reviewers @Divy123 @bhavayAnand9 @Mridul97 @avsingh999 @romanrodriguez @Dhiraj240 @codeIriss @rishabhc32 @chirag-singhal @IgorWilbert @vrk99 @pdurbin @HarshKhandeparkar @aashna27

grvsachdeva picture grvsachdeva on 3 Jun 2019

@mohitRJranjan @milaaraujo @kevinzluo @Rishabh570 @sashadev-sky @shubhscoder @sidntrivedi012 @SidharthBansal @cesswairimu @stefannibrasil @ViditChitkara @tech4GT @mridulnagpal @IshaGupta18 @CoderJolly @namangupta01 @sagarpreet-chadha @Souravirus @MayankKashyap @siaw23 @ryzokuken @icarito @steviepubliclab, @ebarry, @jywarren, @sagarpreet-chadha, @JonathanXu1, @uzorjchibuzor, @eli6, @rexagod, @divyabaid16, @dinaelhanan, @oorjitchowdhary, @wanzulfikri, @mohitRJranjan @publiclab/mentors @publiclab/image-sequencer-guides @publiclab/leaflet-environmental-layers-guides @Paarmita @publiclab/reviewers @Divy123 @bhavayAnand9 @Mridul97 @avsingh999 @romanrodriguez @Dhiraj240 @codeIriss @rishabhc32 @chirag-singhal @IgorWilbert @vrk99 @pdurbin @HarshKhandeparkar @niravasher @marieram @publiclab/reviewers @publiclab/is-reviewers @publiclab/community-reps @divyabaid16

grvsachdeva picture grvsachdeva on 3 Jun 2019

@publiclab/community-reps @subhahu123 @An0u @Jaya738 @mgroovyank @shreyateeza @TANGL3SIT3S @nazeem1988 @karunagoyalk @Nirvikalpa108 @cassianoblonski @EngrEric @Anjalizi @GettyOrawo @coderbeetle @corbettbw @govindjeevan @gautamig54 @daddyjab @emestabillo @letnewKid @srujana121 @jazdao @ChinwenduSilvia @aggarwal19 @Jenniline @madelinejones @helenatxu @richa031 @fabsar @kuja24 @megha070 @Aarabhi2017 @Manvi07 @siddhishree @Julius26 @VinneyJ @sonali9696 @rarrunategu1 @coreytegeler @labseven @milomacphail @CleverFool77 @ananyaarun @ananya @publiclab-mimi @shubhi2000

grvsachdeva picture grvsachdeva on 3 Jun 2019

@Priyak5 @techchic @ananya @hc-barker @edwd42 @PritiShaw @themonster2015 @supriya-kotturu @AnthoniaOkafor @scheleon @mahmodHammad @santushk @jillpena @stoic-plus @starkblaze01 @aSquare14 @vaarigupta @alonpeer @madeofhuman @ibnjunaid @aashna27 @harshithpabbati @mmmelissa @rarrunategu1 @daz @UNnamed66 @GauravJ3 @Greg-Tarr @Sanscripter @hodbadger @alaxalves @becomingajunior @monsij @vrk99 @pdurbin @HarshKhandeparkar @aashna27 @Harshithpabbati @CleverFool77 @niravasher @gautamig54

grvsachdeva picture grvsachdeva on 3 Jun 2019

@jesus-montano @michelelong

grvsachdeva picture grvsachdeva on 3 Jun 2019

Hi, all! After last week's discussion on having an Open Call for Code tomorrow, this time seems to have been the most selected:

image

That will be this time in any timezone: https://everytimezone.com/s/96b47522 (corrected)

(referencing @gauravano in this comment):

Hi everyone, we are planning to hold an Open Call for Software community where they can ask their questions, share their experiences and much more. Also, we would be discussing some topics like Testing, reviewing process, Unstable usage, etc.

The Open call will take place on June 4, 2019, Tuesday. Please express the time you're comfortable with https://www.when2meet.com/?7871820-tR6Vk

To join Open Call, you'll need a Zoom account and app/chrome extension, and to visit this page: https://pad.publiclab.org/p/opencall

Thanks! I hope to see a lot of you there, we had great response on the form! @ananya @CleverFool77 @gauravano @divyabaid16 @cesswairimu @gautamig54 @IshaGupta18 @rexagod @sashadev-sky

And @starkblaze01 my apologies, you were listed as not being able to make it but perhaps you can join late... and in any case we hope this will be the first of several! We will try to video record it as well.

jywarren picture jywarren on 3 Jun 2019

Did I just miss the open call? It's showing 1 am IST on Tuesday.

Divy123 picture Divy123 on 3 Jun 2019

Yikes! Maybe I did it on the wrong day - it should be 12:30 PM tomorrow - so in about 18.5 hours!

Let me double check the time link. Sorry!

jywarren picture jywarren on 4 Jun 2019

Oops! Indeed i made a mistake. Sorry!!! This is the correct one: https://everytimezone.com/s/96b47522

I'll update the link above too just so people don't press the wrong one. This is in ~18 hours, right?

jywarren picture jywarren on 4 Jun 2019
👍1

Hello!
I will try to make it to the call tomorrow. Last week I cloned the spectral-workbench.js repository and started to try to understand it. Doing that, I ended up installing and learning how to use node.js (from the w3schools tutorial), which is really really awesome! My goal this week is to get a better understanding of how the spectral-workbench.js is organized and to be able to run it as-is on my computer, so then I can start making a contribution.

Navigating the file organization of spectral-workbench.js is where maybe having someone explain it to me would help a lot, but I'm not quite sure who to ask.

cryptoclidus picture cryptoclidus on 4 Jun 2019
🚀1 🎉1

Can someone pleasse help me with the link to the open call?

Divy123 picture Divy123 on 4 Jun 2019

Can someone pleasse help me with the link to the open call?

https://publiclab.org/wiki/open-call

starkblaze01 picture starkblaze01 on 4 Jun 2019
👍1

Hi, all! After last week's discussion on having an Open Call for Code tomorrow, this time seems to have been the most selected:

image

That will be this time in any timezone: https://everytimezone.com/s/96b47522 (corrected)

(referencing @gauravano in this comment):

Hi everyone, we are planning to hold an Open Call for Software community where they can ask their questions, share their experiences and much more. Also, we would be discussing some topics like Testing, reviewing process, Unstable usage, etc.

The Open call will take place on June 4, 2019, Tuesday. Please express the time you're comfortable with https://www.when2meet.com/?7871820-tR6Vk

To join Open Call, you'll need a Zoom account and app/chrome extension, and to visit this page: https://pad.publiclab.org/p/opencall

Thanks! I hope to see a lot of you there, we had great response on the form! @ananya @CleverFool77 @gauravano @divyabaid16 @cesswairimu @gautamig54 @IshaGupta18 @rexagod @sashadev-sky

And @starkblaze01 my apologies, you were listed as not being able to make it but perhaps you can join late... and in any case we hope this will be the first of several! We will try to video record it as well.

Hi, I will try my best to make it on time.
Sorry, for the inconvenience.

starkblaze01 picture starkblaze01 on 4 Jun 2019
👍1

Hi Everyone !!
I'm Ananya an outreachy intern with Public Lab, working on Leaflet Environmental Layers repository.
Here is the jist of my project https://github.com/publiclab/leaflet-environmental-layers/issues/173

Update on last week's progress -

FTO's created by me

Progress of my project

here are some issues/PR's I worked on last week.

PR's reviewed by me

Work done last week

The first half of last week I was not able to work as planned as I was down with viral fever.
In the later half I worked on some pending PR's in plots2 repo. I also worked on changing css of LEL menu based on the recent style guide and some other UI changes as well.
My PR to remove the redundant code and refactor index.html file of the LEL repo was merged last week and the repo builds now !!

Goals for next week

I will open a PR for categorizing layers soon. I also wan to look at the static html page built by @rarrunategu1 and see how it can be integrated with the layers.
I'll also open a few FTO's and continue helping and reviewing PR's as much as i can !!
I have been facing some difficulty in signup validation issue, I'll try to fix this as well.

Regarding the next phase of my project that is from the next week or so , I am a bit unsure on how to start and go about with the removal of redundant code between layers and standardizing layers considering LEL is a growing library with many different layers. It would be great to discuss with my mentors @sagarpreet-chadha @gauravano @jywarren anytime possible. Thanks !!

Thanks everyone !!!
Have a great week ahead :smiley:

I shall soon post a second blog post about my experience and challenges faced till now :)
https://ananyaarun8.wordpress.com/

ananyaarun picture ananyaarun on 4 Jun 2019
🎉4 👍3

Thanks to your welcoming project I have created my first issues, made my first pull requests and had a PR merged this week. I have been looking to make a contribution for a long time, but wouldn't find a comfortable place to learn how to do it.

Thank you all for making an effort to include everyone.

michelelong picture michelelong on 4 Jun 2019
🎉5 🚀4

Oh no, @ananya i hope you're feeling better!

@michelelong welcome!!! So glad you have found a place here! Awesome! 🎉

jywarren picture jywarren on 4 Jun 2019

Hi everyone, the Code Open Call went well!

Notes here (you may need to scroll down): https://pad.publiclab.org/p/opencall

People are very into the idea of doing it weekly. Would the same time work for enough people each week?

Even if not everyone can, I encourage @publiclab/mentors to offer a time to meet at least every 2 weeks!

jywarren picture jywarren on 4 Jun 2019
👍2

@rexagod it was great hearing about your project. Can you link us there? The demo is cool! Do you have plans to make a headless test suite too, and/or a demo that is visually interactive? Thanks!

jywarren picture jywarren on 4 Jun 2019

And copying in the section on brainstorming on the reviewing process and also more regular calls!

    - Improving Process of Reviewing PRs and issues - 
    - can be hard to get responses from mentors at a given time!
    - TODO: publish list of mentors
- chatroom organization discussion: https://github.com/publiclab/plots2/issues/5819
- challenge of mentioning everyone and inboxes getting too full to notice. 
- 
Lekhika - I actually agree with the Isha's suggestion. It would be great if we could have some schedule for summer of code.
We can work for PR review process.
- Divya Baid: Even I agree with Isha. I think there must be atleast one call per week with the mentors to discuss all the pending issues and to check whether everyone is on the same page.

- ananya - +1 
- Gautami - This idea will be a great help for UI improvements as we have many changes in the design. It will help us add our own suggestions to the design
       - TODO: Time(s) for regular calls - in big group or small groups?
         - this time each week?
- gaurav can be available - mentoring 5 projects
- will check with other mentors about this possibility

@gauravano shared: Summer of Code projects: https://github.com/publiclab/plots2/wiki/Summer-of-Code-2019-projects

jywarren picture jywarren on 4 Jun 2019

I heard a 👍 from @IshaGupta18 and @rexagod on next week same time -- anyone else? Just leave a 👍 if you can and perhaps a 👎 if you need another time? (I won't be sad don't worry!)

jywarren picture jywarren on 4 Jun 2019
👍4

Count me in, wasn't aware of the call taking place. Will surely love to attend next time @jywarren

CoderJolly picture CoderJolly on 4 Jun 2019
🎉2 👍1

@rexagod it was great hearing about your project. Can you link us there? The demo is cool! Do you have plans to make a headless test suite too, and/or a demo that is visually interactive? Thanks!

Thank you, @jywarren! I'm assuming by demo you mean the matcher-core's demo, right? Anyway, talking about matcher-cli, yes, it's a headless testing utility for locally (and travis-friendly too 🎉) testing out your matcher-core configs, i.e., it starts a local server and deploys your current configs on the specified port which happens as soon as it's initialized in a node env. After that, based on the functionality CLI offers (currently rich matches -- matcher matches, and detected keypoints -- matcher corners are supported) one can check how well the algorithm runs under their modifications, right in the CLI, based on the number of detected rich matches (directly proportional to better params). This particular functionality could come in handy in scenarios where the user is dealing with rubbersheeting a bunch of say, tropical rainforest images together, and can quickly spin up the CLI to check which config of matcher-core works best for them to sniff out most matches in a "green-dominated" RGB spectrum, or if say the user wants to keep a check on the performance of the algorithm and if the current configs are increasing the load time, they can check that out as well since the matcher-cli env employs an actual headless chromium page, so one can be sure that the results are indeed realtime and accurate.

I've recorded a session of the demo, and you can check it out by clicking here.

@jywarren I'll talk more about this in the next opencall, given my connection stays strong (sorry for today, I would have explained this more if the connection wasn't so unstable)! Also, can PublicLab fork these repos so I can get everyone's feedback on them since I believe that both of them have reached a saturation point and can be safely shifted here for further development. Thank you!

(Also, in case anyone missed it, you can checkout the core and cli repos on these links. Drop a star while you're at it!⭐)

rexagod picture rexagod on 5 Jun 2019
🎉2 👍2

Also, in response to this week's check-in,

FTOs created in the previous week

New: https://github.com/publiclab/mapknitter/issues/663#issuecomment-498852814
Ongoing: (all listed here) https://github.com/publiclab/inline-markdown-editor/issues/72

Progress for your project

CLI and Core are already on their v1.0.0 releases and I'll be publishing them very soon. Refer above comment for more details.

Upcoming week's goals

Developing matcher UI using leaflet and finalize a detection strategy for auto-stitcher module.

PR reviewed by you in the previous week

https://github.com/publiclab/image-sequencer/pull/710
https://github.com/publiclab/Leaflet.DistortableImage/pull/255
https://github.com/publiclab/simple-data-grapher/pull/29

Work completed last week

Refer above.

What things you did collaboratively last week? This is really important we want team spirit.

https://github.com/publiclab/simple-data-grapher/pull/29
https://github.com/publiclab/community-toolbox/pull/213

rexagod picture rexagod on 5 Jun 2019
🎉2 👍2

Something I have leaned from contributing with PublicLab projects was about the Rails Asset Pipeline. During some upgrades I've done/have been doing on Mapknitter, I got to learn a lot about it. Also I have learned about the tool Gitter, something that I have never even heard about. Pretty nice tool though.

alaxalves picture alaxalves on 5 Jun 2019
❤3 👍3 🎉2

From PL, I learnt modularity, testing, mentorship, and various prod environments. These I can't understand without PL. Thanks

SidharthBansal picture SidharthBansal on 5 Jun 2019
🎉1

@alaxalves I think you forget to mention the updates. Please do it in your free time here.
Thanks

SidharthBansal picture SidharthBansal on 5 Jun 2019

@alaxalves I think you forget to mention the updates. Please do it in your free time here.
Thanks

This week I worked a lot with Rubocop settings and patches. At https://github.com/publiclab/mapknitter/pull/547 and https://github.com/publiclab/mapknitter/pull/661. I have also fixed our issue that made Travis use the production environment. So now Travis is using the test environment as it should. Right now I'm working on some issue regarding CodeCov @kaustubh-nair has identified (I'll open a PR soon), I have also started working with @cesswairimu to get Mapknitter on Rails >4 already. Along with Kaustubh I have suggested for us to merge our update to a sort of unstable branch, We'd like you to discuss things here -> https://github.com/publiclab/mapknitter/issues/665 as @jywarren suggestd on Gitter.

alaxalves picture alaxalves on 5 Jun 2019
🎉2 👍2

Hello everyone!
Hope everyone is doing great!

My update on last weeks progress:

Issues created:
https://github.com/publiclab/mapknitter/issues/638
https://github.com/publiclab/mapknitter/issues/644

FTO'S created:
https://github.com/publiclab/mapknitter/issues/639
https://github.com/publiclab/mapknitter/issues/647

PR's worked upon:
https://github.com/publiclab/mapknitter/pull/645
https://github.com/publiclab/mapknitter/pull/640
https://github.com/publiclab/mapknitter/pull/653
https://github.com/publiclab/mapknitter/pull/650
https://github.com/publiclab/plots2/pull/5816

This week I will be working with image export in the sidebar in mapknitter. This is a new thing for me so it migth take some time but I'm very much excited to do this.
I ask everyone and my mentors to please provide their reviews on 653 and 640.

Wish everyone a great week. :tada: :tada:

Thanks!

divyabaid16 picture divyabaid16 on 5 Jun 2019
👍3 🎉2

Hi all :wave:,

I am calling for anyone with a moment to spare to kindly take a look at the upgraded version of mapknitter (Rails 4) on http://mapknitter-unstable.laboratoriopublico.org/. If you come across any bugs or any broken parts please leave a comment at https://github.com/publiclab/mapknitter/issues/668. Thanks in advance :heart:

It was great seeing all those who made it to the call yesterday :smile:
Have a good rest of week everyone!

cesswairimu picture cesswairimu on 5 Jun 2019
🎉2 👍2

Hi, I have observed some SoC fellows not answering much on threads where they are mentioned. Also, they are not giving updates here. It will be really nice if you all can join in and we can come across your progress.
These checkins help mentors to judge how much effort you wrote and you are able to put in. We focus on the efficiency of our mentees so that we can discuss and improve it.
Without it, it is difficult for mentors to draft the feedback on the main SoC program websites.

So, please reply swiftly and consistently within 24 hours of pinging.
In case you are busy. Please tell us. We should now whether you are on the right track or not.

SidharthBansal picture SidharthBansal on 8 Jun 2019

I am highly busy for June and July. Will be active from August onwards.
But you can still ping me on my personal email address in case of any help. Even if anyone have stress issues, please consult with the mentors. We are there to help you. :-)
Thanks

SidharthBansal picture SidharthBansal on 8 Jun 2019
👍1

Hi, everyone - i just submitted initial feedback from mentors for our Outreachy fellows. Congratulations!

I wanted to share that I wrote this blog post a few years ago after our first really big summer of code, and some of the "lessons we learned" we are still learning :-)

https://opensource.googleblog.com/2016/12/google-summer-of-code-2016-wrap-up_21.html

Below is the original draft which is a bit longer and written more directly for fellows and mentors, which you might find interesting. I may post a link in the Weekly Check-In as well.

(written in 2016) I just wanted to say that, although we’ve has some amazing summers in the past, this summer was once again our most successful summer yet. I think our continuous refinement of the planning process and how we run our unique Summer of Code process has really grown and allowed us to have:

  • More projects succeeding
  • More and better documentation
  • Clearer onramps for new contributors written by students who can build out their own contributor mini-communities over the summer
  • Better constant communication and inter-student collaboration
  • More modular, easy-to-integrate projects
  • More tests
  • Better work plans
  • An earlier, faster start to the summer

You can read more of the specific highlights of our projects on the most recent Web Working Group update. But I wanted to share some of the reflections, advice, thoughts, and ideas I’ve had over the course of this unique summer. I wrote some of this into each of your evals, but without sharing feedback specific to a given student, I wanted to share my notes. Apologies to non-coders if they’re very software-oriented, but I think some of these apply to non-coding projects too!

Turn your remaining work into well-documented onramps for new contributors

To students who are approaching the end of their projects, an important step is re-assessing what's left, and what they can finish up in the remaining time. But rather than considering any unfinished pieces "missing", it’s great to take them as an opportunity to invite others into your projects, by turning them into well-documented issues on your project repositories.

If you offer enough context, you should be able to recruit people to take up the remaining tasks once the summer ends, and whether or not you continue work afterwards, folks will be able to carry your work forward. This may mean writing a first-timers-only issue, for example, to welcome a new coder into the project.

Mentors: I think it's great to encourage students to document their work (and what's left to do) as issues that are up for grabs. It's better for morale to plan ahead for other people to pick up where you left off, and to think about your project living on, than to focus on asking them what they didn’t do! And it’s better for the project overall anyways!

Write issues for yourself, but as if written for others

Ask students to write one new issue per week for someone else, which helps them think in terms of how others read their work, and encourages them to break up projects into smaller parts that newcomers can tackle. Good code is modular, not a spaghetti -- and looking at it from the outside is a powerful way to improve your planning and style.

Learn how to develop a small community of contributors around your work

Over the course of your work, you've all become leaders in this community through your work, your collaboration, and your major contribution to the platforms we use at Public Lab. Take a look at this page for some ideas on how you can ensure your projects live on: https://github.com/publiclab/plots2/projects/4

Write onboarding or “first-timers-only” issues

I think asking or even requiring projects to have "onboarding" or "first-timers-only" tasks during the recruitment phase can help improve the overall success of the project and ensure project teams are giving students the support they need early on. This also helps ensure that students have installed everything and gone through the “PR merging” process before they even begin work!

Learn how to write a good, step-by-step first-timer issue

Start your summer by thinking about building a team by inviting others into your work. It’s a key skill for any software developer, and it’s never too early to think about documentation, or about designing for reuse and for other coders to read your work. As someone who’s probably just gotten the project installed and set up, you’re also uniquely equipped to guide others through that process! And it’s a good habit both for yourself (to break down and articulate problems in writing) and for future coders. Here’s a guide to writing issues for newcomers:

https://publiclab.org/notes/warren/10-31-2016/create-a-welcoming-first-timers-only-issue-to-invite-new-software-contributors

See your own work through others’ eyes

Towards the end of the summer, begin to consider how other people (who program) will use your work. Will they understand how to install it? How to adapt it to their own uses? Will they have trouble setting it up, or be confused at how things are named or organized? What can you do to make it easier for others to pick up your work and use it? A good demo? More clear documentation or examples? One great way to know if your work is readable is to ask one another to read it over and provide feedback.

Break your work into small parts!

Students love to make giant projects that are all intertwined, and it takes discipline to break things into small, testable parts. But be hard on the students early on -- resist the temptation to just say “code the whole thing up as fast as you can!” since it can really be worth the time to work with them to plan out and break down their work. It’s much easier to build on smaller self-contained modules that are clearly tested than to sift through huge amounts of less structured code, whether it’s the students themselves doing it or you taking over at the end of the summer. It’s also just good coding practice!

Write a planning checklist that you can work on chunk by chunk

Write a planning issue early on, based on your proposal. Take the overall goals and break them into parts small enough that you can merge them (with tests) into the trunk branch one at a time. Before a user-facing feature goes live, you can merge in a whole set of back-end functions which underpin it, and ensure they are all working in production before making the UI that exposes it to the public.

Break things into a checklist with "phases" and really modularize down into distinct steps as much as possible, like in this example:

https://github.com/publiclab/leaflet-blurred-location/issues/1

It's a really great way to visualize your progress over the course of the summer, and a good first step to developing a milestones.

Publish “hidden betas” to test your work in production

When students want to publish a public-facing interface (a new feature) but you’re not sure it’s perfect yet, allow them to publish it in a way that’s hidden, so you can see how it does “in the wild.” For web projects, only enable it if people add a ?beta=true parameter to the URL. For desktop projects, hide it behind a flag, like --enable-beta-features. That way, they can break up the work into smaller parts, and can get feedback from the real community as they refine their work. Just be sure the flags are clearly marked and can be removed by another contributor later.

Do you have more to suggest? I’d love to hear your tips -- leave them below in the comments.

Some of these you already know. But perhaps some may also help you chart and adjust your course now that you have a few weeks of work behind you!

Thanks everyone! 🎉 🙌

jywarren picture jywarren on 8 Jun 2019
❤8 👍6 🎉3 👎2

@publiclab/soc take a look!

jywarren picture jywarren on 8 Jun 2019
👍4 ❤1

@jywarren this is lovely blog post! Really informative.

My updates on the GSoC Sensor Data Project:

We merged a very big PR https://github.com/publiclab/simple-data-grapher/pull/29 which implements the class structure in the code. This PR, however, needs further breaking down and some more set-up help in the local environment (https://github.com/publiclab/simple-data-grapher/issues/33)

I have been working on linting and have set-up eslint for the project locally, which I will be pushing once the above bug is resolved.

We can now import CSV data from a published Google Sheet (https://github.com/publiclab/simple-data-grapher/pull/32) and plot charts with it.

Discussions are going on and me and @jywarren are exploring various export options (https://github.com/publiclab/simple-data-grapher/issues/17)

Work on browsable time-slider is also going on, however, due to some breaking in the CDN, we may have to think of an alternate solution (https://github.com/publiclab/simple-data-grapher/pull/31)

This week, I plan to:

  • Work on UI design of the library

  • Break some of the bigger code into smaller class functions

  • Work on an export option

Also, I wanted to discuss the possibility of shifting to plot.ly instead of chart.js, for its more comprehensive features and better analysis of data. I would love to hear your views at https://github.com/publiclab/simple-data-grapher/issues/34

Thanks a lot and have a great week everyone!

cc: @jywarren @namangupta01 @sagarpreet-chadha @IgorWilbert @gauravano @Souravirus @SidharthBansal @geekychasser

IshaGupta18 picture IshaGupta18 on 8 Jun 2019
🚀2 🎉2 👍2

Hi everyone :smiley:,
I hope everyone's doing great!

The project I'm working on is community-toolbox :computer: and my project's milestones can found here.

Updates

Goals for the upcoming week

I'll be working on the dropdown for navigation around different repositories, a filter for recent contributors' list and adding a night-themed mode.
I'll try to create more FTOs along with PR reviews.

Thanks!!! :smile:
Great theme @aSquare14 :tada:

Rishabh570 picture Rishabh570 on 9 Jun 2019
🚀2 🎉2 👍2

Thanks Rishabh Rawat ! :)

On Sun, Jun 9, 2019, 6:12 PM Rishabh Rawat notifications@github.com wrote:

Hi everyone 😃,
I hope everyone's doing great!

The project I'm working on is community-toolbox 💻 and my project's
milestones can found here
https://github.com/publiclab/community-toolbox/projects/1.
Updates

Goals for the upcoming week

I'll be working on the dropdown for navigation around different
repositories, a filter for recent contributors' list and adding a
night-themed mode.
I'll try to create more FTOs along with PR reviews.

Thanks!!! 😄
Great theme @aSquare14 https://github.com/aSquare14 🎉

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/5828?email_source=notifications&email_token=AFPAIVJEPD2OBFG32XFOVJLPZT3DZA5CNFSM4HSQ4T42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXIJL5A#issuecomment-500209140,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFPAIVIX3ORNQROWCQE2ZBTPZT3DZANCNFSM4HSQ4T4Q
.

asquare14 picture asquare14 on 9 Jun 2019

Hi everyone :)
I've learnt a lot while working with Publiclab.
In the past few months I've learnt about so much about testing, docker, travis and the rails asset pipeline :smile:

Updates for the Mapknitter rails upgrade project

Work done

Add tests for controllers
Add tests for models

Currently working

Switch from Bower to Yarn

I'd like to reiterate what @cesswairimu said... please test out the mapknitter rails 4 upgrade and drop a comment at https://github.com/publiclab/mapknitter/issues/668 if you find any issues so me and @alaxalves can get started with Rails 5 asap.
Thanks!

kaustubh-nair picture kaustubh-nair on 9 Jun 2019
🚀2 🎉2 👍2

Hi, anybody interested in opening this week's check-in?

grvsachdeva picture grvsachdeva on 10 Jun 2019

Hi all, I can repost this when someone opens our this week check-in but here for now:

Welcoming reminder that tomorrow we will convene for the 2nd Edition of Code Open Call!

Time: Jun 11, 2019 12:30 ET / 16:30 UK / 22:00 India

Link: https://zoom.us/j/440795826

Notes will be here: https://pad.publiclab.org/p/opencall (use the upper right hand button to add your name and choose your color!)

We may experiment with Zoom Breakout rooms for each project to have a small meeting simultaneously.

ebarry picture ebarry on 10 Jun 2019
👍1

Hi everyone, new check-in is at https://github.com/publiclab/simple-data-grapher/issues/41. Thanks!

grvsachdeva picture grvsachdeva on 11 Jun 2019

Great planning folks!!!

SidharthBansal picture SidharthBansal on 15 Jun 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jywarren picture jywarren  ·  3Comments
divyabaid16 picture divyabaid16  ·  3Comments
milaaraujo picture milaaraujo  ·  3Comments
grvsachdeva picture grvsachdeva  ·  3Comments
ebarry picture ebarry  ·  3Comments