Open jywarren opened 5 years ago
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
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?
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 ?
@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: .
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 notifications@github.com 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 .
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 notifications@github.com 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 .
I've also added a Planning Issues section above!
Here are some related comments -- :mag: facts, :heart: feelings, and :bulb: ideas:
OWNERS
is a file format for declaring who's accountable for sections of repo.
probot-owners
plugin that @mentions any GitHub member into PRs based on the OWNERS
file.CODEOWNERS
format. (why)
CODEOWNERS
features require write-access to repo.OWNERS
is better because it doesn't favour code.OWNERS
might be a good way to manage a team-like process.OWNERS
files can be updated and discussed via PR.OWNERS
file into a semi-formal process of giving people ownership of certain areas of codebase as interests emerge.
# 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 :)
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!
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)
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? 🎉
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! 😄
@sashadev-sky tried out the naming ppl in releases idea here: https://github.com/publiclab/Leaflet.DistortableImage/releases -- it looks very cool!
@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.
@jywarren Yes I really like it because 1) It's good documentation 2) We can give credit especially to people that completed an FTO!
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!
@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!!!
@jywarren @everyoneelse I'm happy to add whatever you guys would like to the README. just let me know!
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.
That's a great idea Siddharth.
On Fri, May 17, 2019, 10:05 PM Sidharth Bansal notifications@github.com 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 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:
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!
Hi, all! New call for SoC mentors for 2020 is up here! https://github.com/publiclab/plots2/issues/7360
Great! Referenced this and built on it in https://github.com/publiclab/plots2/issues/7873 ❤️
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
* [ ] 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...Weekly workflow
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 inplots2
?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:
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 ?
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?