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

[jywarren]

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

• Who to ask for help: (and on what topics) @publiclab/community-reps, @publiclab/mentors, @publiclab/reviewers @publiclab/plots2-reviewers @publiclab/is-reviewers ?

  • consider joining the Reviewers team here: Call for reviewers and co-reviewing workflow ⚡️ #4707 and for image-sequencer, Call for reviewers group and new co-reviewing workflow image-sequencer#656

• Guidance on design: We have a Style Guide draft that we'll be publishing very soon that will be VERY helpful for making our design more cohesive
  UPDATE: Please find the draft style guide link in this note - https://publiclab.org/notes/warren/05-07-2019/introducing-a-draft-style-guide-for-public-lab

• New features versus working on addressing existing issues?

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?

[sashadev-sky]

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]

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]

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]

@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]

There are two things to consider Sagar, will the calls group calls or 2 people calls or both?

…

On Tue, May 7, 2019, 1:57 PM Sagarpreet Chadha ***@***.***> wrote: @SidharthBansal <https://github.com/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 💯 . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5667 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAAEQ3JPLS7AXDEIE6YGNDPUE4NJANCNFSM4HLEHPRQ> .

[SidharthBansal]

Sasha I liked your idea a lot. Initially we tried the system of credits at time of GCI, but we have to do a lot of overhead work. Like deciding which PR should be given how much credits and so on. We ultimately closed that issue as we wanted positive support instead of competition. In case we want to implement this then we need to decide a lot of parameters. We can reopen the previous issue. What do you all suggest? On Tue, May 7, 2019, 8:06 PM Sidharth Bansal <bansal.sidharthcode@gmail.com> wrote:

…

There are two things to consider Sagar, will the calls group calls or 2 people calls or both? On Tue, May 7, 2019, 1:57 PM Sagarpreet Chadha ***@***.***> wrote: > @SidharthBansal <https://github.com/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 💯 . > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#5667 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFAAEQ3JPLS7AXDEIE6YGNDPUE4NJANCNFSM4HLEHPRQ> > . >

[jywarren]

I've also added a Planning Issues section above!

[patcon]

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

• 🔍 OWNERS is a file format for declaring who's accountable for sections of repo.
  • 🔍 There is a probot-owners plugin that @mentions any GitHub member into PRs based on the OWNERS file.
• 🔍 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]

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]

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)