Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Compiling a "how we work" document (esp for Outreachy/SoC) #5667

Open
jywarren opened this issue May 6, 2019 · 24 comments
Open

Compiling a "how we work" document (esp for Outreachy/SoC) #5667

jywarren opened this issue May 6, 2019 · 24 comments
Labels
brainstorm Issues that need discussion and requirements need to be elucidated discussion outreachy summer-of-code support

Comments

@jywarren
Copy link
Member

jywarren commented May 6, 2019 •
edited by grvsachdeva
Loading

Following up on the call today we have many good ideas for how to better organize and present our "cooperation style" and workflows. Some are good recommendations. Some we might choose to adopt more officially. Almost all bear some discussion. I want to try to make a list here, choose maybe 5 or so of the top that have most consensus, and start with those -- we can refine/revise/revisit later as well!

Getting started

  • Planning issues: It's a great idea to start a new planning issue with a checklist (using GitHub's * [ ] item syntax!) -- see the "modularization" blog post in https://publiclab.org/software-outreach for help with this. This is also a great way to coordinate with other team members... for example...
  • Coordination over shared projects w multiple people (how to divide up the work) -- can we get some recommendations here, and can people greet others they'll be working with (if they haven't already)? Start to talk about what parts of the projects they would like to collaborate on, or are happy to have someone else take up? There's plenty of work 🎉
  • Shall we try to coordinate schedules, in a new post? (both timezones, and holiday/exams schedules)

Weekly workflow

  • Check-ins: Saying hello and providing an update in the Check-In
    *.Participating in Check-Ins instead of blogging, unless you have something bigger to announce?

Reviewing

  • Requiring tests: Formalizing our reviewing workflow: at image-sequencer we are leaning towards requiring tests with any PR (except FTOs). Shall we do the same in plots2?

  • Promoting System Tests: for any plots2 feature that involves JS + Ruby, since these systems are delicate and have been breaking more recently (comment posting, image uploading, login sequence)

  • Requiring 2 reviews, (at least one from a mentor or reviewer?)

  • When a PR is stuck:

    • Sometimes the majority is done, and can be merged, and stuck sub-issues can be broken out and solved next -- sometimes a PR starts to get bigger as we add more into it, so consider this!
    • When you can't get feedback or input enough, try the chatroom https://publiclab.org/chat or chime in at the Weekly Check-In and ask for some help! (Pinned at: https://github.com/publiclab/plots2/issues)
    • If you need to try it out in a test server, try our unstable server at https://unstable.publiclab.org (we'll post a how-to) -- especially database changes, or where you need more test data to see it working.

Getting help/input

I'd also like to propose a ROADMAP which can help us to set a cohesive direction as a community. I've been talking with @publiclab/community-reps about this and have some ideas I will share soon.

What else? And what of these do you really like or support?
@jywarren jywarren added summer-of-code outreachy brainstorm Issues that need discussion and requirements need to be elucidated discussion labels May 6, 2019
@jywarren jywarren mentioned this issue May 7, 2019
Closed
11 tasks
@sashadev-sky
Copy link
Member

sashadev-sky commented May 7, 2019 •
edited
Loading

Hi!
Here are some ideas I have, feel free to add them to the list if you like them @jywarren:

  1. I got this idea directly from the GSoC mentor guide, and its more of an idea to implement on PL's side rather than the student, but for Github releases I was thinking we could start listing specific bug fixes and giving credits to those who fixed them. An example of a repo that does this is https://github.com/Leaflet/Leaflet/releases and I really like it! It has to do with the fact that OS is a reputation economy and it's motivating to give credit to students
  2. Maybe creating an official checklist doc for all the things to accomplish in the bonding stage? And asking that each student / mentor pair check off all the boxes. I would be happy to make one.
  3. Are we using special labels for issues or PRs having to do with GSoC / Outreachy ?
  4. What if blogging became something that students and mentors do collaboratively?

I've never done this program before so I don't know what are specific things to target that we would like to improve on this year. But, since we have such a large group this year these suggestions are tailored for organizing student / mentor communication

@SidharthBansal
Copy link
Member

We can plan for weekly video calls to increase the team spirit. If mentors are less available than we can have it alternate weeks.
What do you all say?

@sagarpreet-chadha
Copy link
Contributor

Really liked the idea of giving credits in the github release page @sashadev-sky 😄 , especially as this will give recognition and motivation to people .

A good thing about most of the SoC students is that they are already contributing for a while now and have grasp of how things work in our community , hence we can jump directly to implementation discussion part and maybe start coding early as i , gaurav and Sidharth did during Gsoc'18 . What do other mentors thing ?

@sagarpreet-chadha
Copy link
Contributor

@SidharthBansal ...yes great idea ! This way we can keep track of work in other projects as well OR maybe get some new insights on how we can make mentor-student communication more seamless ?
I am always up for video/voice calling 💯 .

@SidharthBansal
Copy link
Member

SidharthBansal commented May 7, 2019 via email

@SidharthBansal
Copy link
Member

SidharthBansal commented May 7, 2019 via email

@jywarren
Copy link
Member Author

jywarren commented May 7, 2019

I've also added a Planning Issues section above!

@patcon
Copy link
Contributor

patcon commented May 8, 2019 •
edited
Loading

Here are some related comments -- 🔍 facts, ❤️ feelings, and 💡 ideas:

  • 🔍 OWNERS is a file format for declaring who's accountable for sections of repo.
  • 🔍 GitHub has a separate CODEOWNERS format. (why)
    • 🔍 Perks of GitHub's CODEOWNERS features require write-access to repo.
    • ❤️ I feel that OWNERS is better because it doesn't favour code.
  • ❤️ I feel that short-ish term role rotation is a good cyclical way to re-energize ongoing and indefinite processes.
  • ❤️ I feel that OWNERS might be a good way to manage a team-like process.
  • 🔍 Changes to the OWNERS files can be updated and discussed via PR.
  • 💡 Incorporate OWNERS file into a semi-formal process of giving people ownership of certain areas of codebase as interests emerge.
    • 💡 Make role rotation an integral part of a process. Not only does someone do it for a specific defined term (for example, one month), but that when they're nearing the end, the hope is that they recruit and encourage to next person to take over (doing it many consecutive terms is generous, but non-ideal -- invitations are more valued).
    • 💡 If no one is recruited, then the entry is just removed from the owner file, and any less specific entry takes precedent.
  • ❤️ I feel that something like this might allow people to work on PL projects more granularly, without 1) subscribing to the full repo via GitHub's "Watch" feature, nor 2) relying on a steward to ping them in.
# OWNERS
@jywarren *
@doc-steward *.md
@agata subsystem2/*
@marylyn subsystem2/foo.rb

(Bonus points for fun ASCII art styling of the OWNERS file)

So people doing a role can fill it for awhile, but also recruit people to take ownership of smaller parts of the system. I know responsibility often doesn't break down quite so clearly along filesystem lines, so maybe this scheme wouldn't work so well ;)

Anyhow, sorry for the drive-by! I just get excited about all the ways PL is experimenting with grassroots community building over code, and wanted to share the thought :)

@grvsachdeva
Copy link
Member

Check-ins: Saying hello and providing an update in the Check-In
*.Participating in Check-Ins instead of blogging, unless you have something bigger to announce?

I think, we can ask for 2 blogs per month as that would also help the SOC interns in reflecting back on their work, experience and would also help others in knowing the project better.

What if blogging became something that students and mentors do collaboratively?

Hmm, interesting. We can try this.

Requiring tests: Formalizing our reviewing workflow: at image-sequencer we are leaning towards requiring tests with any PR (except FTOs). Shall we do the same in plots2?

Yes!

I'd also like to propose a ROADMAP which can help us to set a cohesive direction as a community. I've been talking with @publiclab/community-reps about this and have some ideas I will share soon.

waiting 😄

Maybe creating an official checklist doc for all the things to accomplish in the bonding stage? And asking that each student / mentor pair check off all the boxes. I would be happy to make one.

Agree!

Are we using special labels for issues or PRs having to do with GSoC / Outreachy ?

Yes, we have gsoc, outreachy, summer-of-code labels feel free to use them at relevant issues @sashadev-sky

And, yes, +1 for weekly call and release idea.

Thanks!

@gautamig54
Copy link
Contributor

gautamig54 commented May 8, 2019 •
edited
Loading

Great ideas @jywarren @sashadev-sky @sagarpreet-chadha @patcon @gauravano !!
I guess we can start by identifying mentors and our fellow applicants with whom we will be collaborating this summer. Maybe create a separate Gitter room for each project with mentors and soc applicants concerning that project. We have to make the best use of the Community bonding period.
Also, each team can decide upon a combined timeline and upload it as a doc on Gitter. This will help a lot in dividing and prioritising work in summer.
I really liked @sashadev-sky's idea about creating a checklist.

PS: It is a great help to maintain a google calendar when working on a project and write down the tasks accomplished by you did on a daily basis. This will help you in monitoring your work and will also help in writing down the evaluation reports. Also, it provides a lot of motivation, when you look back at your journey. (Just a tip for soc applicants as this practice helped me a lot :D)

@jywarren jywarren mentioned this issue May 8, 2019
Closed
@jywarren
Copy link
Member Author

jywarren commented May 9, 2019

Hi @ananyaarun @CleverFool77 -- i know Outreachy has a specific requirement of blogging which we probably cannot convert into "replies in the weekly check-in". However if you'd blog at PublicLab.org with a outreachy-2019 tag, that'd be great. You can see some of @cesswairimu's posts along these lines, and you are free to copy your weekly check-in comments into the blog, so you don't have to write in duplicate. How does that sound? 🎉

@jywarren
Copy link
Member Author

jywarren commented May 9, 2019

And @gautamig54 we are typically trying not to fragment the community too much by making lots of Gitter rooms, but perhaps we can start by just using the existing room and then if people want to break off into the soc room (which is a bit noisy) for very long, in-depth discussions, that'd work? https://gitter.im/publiclab/soc

Or we can make a side room for long discussions, if people feel they're filling up the chatroom too much? Not that chatting a lot is a problem! 😄

@jywarren
Copy link
Member Author

jywarren commented May 9, 2019

@sashadev-sky tried out the naming ppl in releases idea here: https://github.com/publiclab/Leaflet.DistortableImage/releases -- it looks very cool!

@ananyaarun
Copy link
Member

@jywarren Sure sounds great 😃 !!
We can blog at both publiclab.org like @cesswairimu did 🎉 and our own blogging site.
I would be creating a blog atleast once in 2 weeks for outreachy and perhaps we can use that at the publiclab site as well with the outreachy-2019 tag.

@sashadev-sky
Copy link
Member

@jywarren Yes I really like it because 1) It's good documentation 2) We can give credit especially to people that completed an FTO!

@jywarren
Copy link
Member Author

How are we feeling on all these? Perhaps we could start to choose some items from above to move into the README or another markdown doc? Thanks, all! Very cool!

@jywarren
Copy link
Member Author

@alaxalves note the discussion here on which rooms to use: #5667 (comment)

How does this sound to you? Thank you!!!

@sashadev-sky
Copy link
Member

@jywarren @everyoneelse I'm happy to add whatever you guys would like to the README. just let me know!

@SidharthBansal
Copy link
Member

It will be great to divide this issue into some minor issues so that we can discuss the various possibilities we proposed in this issue.
I feel there are many brilliant ideas in this issue which we should plan for.

@asquare14
Copy link
Member

asquare14 commented May 17, 2019 via email

@alaxalves
Copy link
Member

alaxalves commented May 17, 2019 •
edited
Loading

@alaxalves note the discussion here on which rooms to use: #5667 (comment)

How does this sound to you? Thank you!!!

Well I have been using Gitter's publiclab/publiclab for a quite time now and I like the idea of "keeping everybody together" xD. It's better for me that way because I can interact with mostly everybody from the publiclab community - I think - and I can get my questions answered very quickly. If we got a topic that concerns more to gsoc we could use the publiclab/soc channel as you suggested.

Anyway I vouch for #5667 (comment) 😄 😄

@grvsachdeva
Copy link
Member

Hi @publiclab/soc,

As many of you have opened a planning issue for your projects and started collaborating with each other so let's make a doc containing links to all the planning issues of all projects so that mentors and other contributors can browse for your work quickly 😄 . I have created a wiki at https://github.com/publiclab/plots2/wiki/Summer-of-Code-2019-projects , please go ahead, edit the wiki and fill the details of your project.

We can also think of copying that list as issue at plots2 but for now, please go ahead and fill the details (Description can be 2-3 lines).

Thanks!

@jywarren jywarren mentioned this issue Dec 2, 2019
Closed
@jywarren
Copy link
Member Author

Hi, all! New call for SoC mentors for 2020 is up here! #7360

@jywarren jywarren mentioned this issue May 5, 2020
Closed
@jywarren
Copy link
Member Author

jywarren commented May 5, 2020

Great! Referenced this and built on it in #7873 ❤️

@stale stale bot added the stale label Oct 7, 2020
@cesswairimu cesswairimu removed the stale label Oct 7, 2020
@publiclab publiclab deleted a comment from stale bot Dec 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
brainstorm Issues that need discussion and requirements need to be elucidated discussion outreachy summer-of-code support
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests