Plots2: 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: https://github.com/publiclab/plots2/issues/4707 and for image-sequencer, https://github.com/publiclab/image-sequencer/issues/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 :smile: , 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 :100: .

[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 [e-mail]
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
https://github.com/publiclab/plots2/issues/5667#issuecomment-489985408,
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 [e-mail]
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 [e-mail]
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
https://github.com/publiclab/plots2/issues/5667#issuecomment-489985408,
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 -- :mag: facts, :heart: feelings, and :bulb: ideas:

• :mag: OWNERS is a file format for declaring who's accountable for sections of repo.
  
  
  
  • :mag: There is a probot-owners plugin that @mentions any GitHub member into PRs based on the OWNERS file.
  
  
• :mag: GitHub has a separate CODEOWNERS format. (why)
  
  
  
  • :mag: Perks of GitHub's CODEOWNERS features require write-access to repo.
  
  
  • :heart: I feel that OWNERS is better because it doesn't favour code.
  
  
• :heart: I feel that short-ish term role rotation is a good cyclical way to re-energize ongoing and indefinite processes.
• :heart: I feel that OWNERS might be a good way to manage a team-like process.
• :mag: Changes to the OWNERS files can be updated and discussed via PR.
• :bulb: Incorporate OWNERS file into a semi-formal process of giving people ownership of certain areas of codebase as interests emerge.
  
  
  
  • :bulb: 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).
  
  
  • :bulb: If no one is recruited, then the entry is just removed from the owner file, and any less specific entry takes precedent.
  
  
• :heart: 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 :smile:

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)

[jywarren]

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]

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]

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

[ananyaarun]

@jywarren Sure sounds great :smiley: !!
We can blog at both publiclab.org like @cesswairimu did :tada: 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]

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

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]

@alaxalves note the discussion here on which rooms to use: https://github.com/publiclab/plots2/issues/5667#issuecomment-491076876

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

[sashadev-sky]

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

[SidharthBansal]

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]

That's a great idea Siddharth.

On Fri, May 17, 2019, 10:05 PM Sidharth Bansal [e-mail]
wrote:

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.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/5667?email_source=notifications&email_token=AFPAIVLZ4KQ7P5YOA2MR3B3PV3NFRA5CNFSM4HLEHPR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVHZWQ#issuecomment-493518042,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFPAIVN7JX4755YXBTYZBXLPV3NFRANCNFSM4HLEHPRQ
.

[alaxalves]

@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 https://github.com/publiclab/plots2/issues/5667#issuecomment-491076876 :smile: :smile:

[grvsachdeva]

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 :smile: . 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]

Hi, all! New call for SoC mentors for 2020 is up here! https://github.com/publiclab/plots2/issues/7360

[jywarren]

Great! Referenced this and built on it in https://github.com/publiclab/plots2/issues/7873 ❤️