"Feature maintainers" groups to collaboratively manage IS #1633
Comments
|
This is an awesome idea. |
|
Agreed! |
|
@jywarren there are many cooked bug fix PRs which have not been merged. And you are very busy I see. Can I get temporary merge permissions to continue with the bug fix event? |
|
Hi @harshkhandeparkar it has been really tough to keep up. Do we have a |
|
I think almost all PRs are outdated and inactive at this point 😅. |
|
Hi @harshkhandeparkar after #1668 perhaps we can get ahead of this again now! It dramatically simplifies the review process. Thank you and hope you're well! |
|
though, noting #1681 as well... Update: fixed!! 🎉 |
|
It works really well! |
|
Thanks for all the reviews and issue cleanup! |
|
Ah, thought of a new one -- |
|
Can folks volunteer for a specific one and we can start creating the CODEOWNERS listing? Thank you all!!! |
|
I could help out in maintaining modules and core functionalities, while working on #1564 I had to go through a lot of code related to these |
|
definitely module and core! I love cli but idk what changes can be made to it ¯_(ツ)_/¯ |
|
Cool, thanks both! I guess we ought to write a line of description of the
"goals" and "priorities" of each. Harsh, for CLI, my thought is not every
feature needs planned changes -- some can be in "maintenance" status,
meaning the maintainers for that feature are primarily ensuring that it
remains stable and undisrupted, and perhaps slowly increasing test coverage
of it. Make sense?
Whereas the "modules" maintainers might be seeking both to increase the #
of modules, and to increase stability/test coverage of existing ones --
it's up for discussion!
…On Thu, Oct 1, 2020 at 3:15 PM Harsh Khandeparkar ***@***.***> wrote:
definitely module and core! I love cli but idk what changes can be made to
it ¯_(ツ)_/¯
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1633 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6J7G3Y6B4U5WKTMPF7LSITIOTANCNFSM4KX5KBJQ>
.
|
|
Awesome, @daemon1024 is working on an initial CLI test suite and is interested in being a feature maintainer for the CLI featureset, whose goal is OK, if we can get some similar descriptions/goals for other featuresets, we can create the initial CODEOWNERS file. Thanks, all!
What do we think about core goals or test or module goals? I think core ought to be "stability, optimization, backwards-compatibility" maybe? Modules... one could be "making sure it's simple to create new modules" and "standardizing module code and documentation" Tests... maybe "ensure test parity across various use cases including CLI, Node, and browser"? and more? |
|
Should we add this list of goals to the issue body? |
|
Anyone here can edit and add the goals. |
|
I believe core should be "stability, performance and future compatibility". I think we are just breaking IS further due to backwards compatibility and no one uses old browsers with IS anyway. And also, some parts of IS are anyway not compatible with old browsers and node <10 ig. |
|
Oh sorry, so this is a good reason to write these together -- i should clarify - i meant backwards compatibility as in no breaking changes and no adverse effects on existing functions, including core, modules, ui and cli. And yes, we can keep compiling these at the top! |
|
@jywarren I have added some of the goals and priorities to the issue body, please check it out :) cc: @blurry-x-face @daemon1024 |
|
The priorities are absolutely tentative, I just wrote whatever came to my mind. |
|
OK awesome i like them a lot. I propose for module goals:
to add: also, And: "developing compelling use cases for sequences to show off IS functionality, as in #1480" what do you think? |
|
Sure, I'll add it. |
|
Umm, should child teams of is-maintainers be made? We can add these priorities and goals there. |
|
Hmm, cool idea! Yes, we can do that - like is-module-maintainers,
is-core-maintainers? Also, i forget if whole teams can be made
CODEOWNERS...
also maybe interesting --
"round robin" auto review requests to prompt only some people in a team!
https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team=
also really nice "review request scheduling reminders" system here:
https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/managing-scheduled-reminders-for-your-team
maybe useful if teams get bigger, and/or if people don't want to be on the
hook all the time but just a proportion!
…On Wed, Oct 7, 2020 at 12:20 PM Harsh Khandeparkar ***@***.***> wrote:
Umm, should child teams of is-reviewers be made? We can add these
priorities and goals there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1633 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6J7NT5EPJEDWBJ4DVT3SJSINDANCNFSM4KX5KBJQ>
.
|
|
I think teams can be codeowners according to this official blog post. |
|
Awesome. Anyone else @publiclab/is-reviewers want to join a maintainers
team? Any last changes before we start this up? Thanks!!!
…On Wed, Oct 7, 2020 at 1:28 PM Harsh Khandeparkar ***@***.***> wrote:
I think teams can be codeowners according to this official blog post.
https://github.blog/2017-07-06-introducing-code-owners/
[image: image]
<https://user-images.githubusercontent.com/34770591/95366088-9468c700-08f0-11eb-97eb-52aa0e240d06.png>
That(github/js) looks like a team
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1633 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6J2V7ALYZJQBF4MCJM3SJSQMRANCNFSM4KX5KBJQ>
.
|
|
If @blurry-x-face confirms the list then ig we are good to go. |
|
Yea @harshkhandeparkar goals and pririties looks good to me, we can continue with this :) |
|
Great -- Harsh, would you like to open a PR with the CODEOWNERS file
accordingly, and i can review and make the corresponding teams? Thanks, all!
…On Thu, Oct 8, 2020 at 3:06 PM Rishabh Shukla ***@***.***> wrote:
Yea @harshkhandeparkar <https://github.com/HarshKhandeparkar> goals and
pririties looks good to me, we can continue with this :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1633 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6JZC6PGCLK72NSYT7UDSJYESNANCNFSM4KX5KBJQ>
.
|
|
Umm. I don't exactly know what a CODEOWNERS file is 😂. |
|
Ah, my apologies - the CODEOWNERS file is what drives this feature -- see this PR -- https://github.com/publiclab/plots2/pull/6502/files Make sense? what do you think? |
|
Where can I find the docs for it? |
|
Actually, I don't really need to. @jywarren Can you make the teams though? |
|
OK, folks, invited you too -- but i set the checks to 2 approvals required just while we try this system out. Thanks, let's take it one step at a time and we can prob lower that threshold soon. |
|
@jywarren I would be most interested but I would like to start work on the project once again first and see some of the amazing recent advancements, it has made to which I get accustomed to!!! Thanks a lot for considering! Will love to be a part here soon!! |
|
Hi all! How are we feeling about the workflow, given we just published a new release, we now have a checklist for releases #1692 and we are getting ready with both a project and a milestone for Should we drop the # of reviews required down to 1? Or are we OK as it is? Also, i'll re-open this so we can recruit more maintainers and just have more dialogue. Thank you! |
|
(I couldn't find a better issue to discuss this) Thanks. |
|
Sure, i was just more familiar with milestones. Do you think all the existing entries in the v.3.7.0 milestone could go into the 3.6.1 project, and secondly, do you want to rename 3.6.1 project to 3.7.0? What are your thoughts? thanks! |
|
I am ok with both. |
|
I just created a sort-of template release project. |
|
oh awesome idea!!!!
…On Sun, Nov 1, 2020 at 11:55 PM Harsh Khandeparkar ***@***.***> wrote:
I just created a sort-of *template* release project.
[image: image]
<https://user-images.githubusercontent.com/34770591/97831344-b7bb4200-1cf5-11eb-9314-f45682465840.png>
We can copy this from the menu.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1633 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6JYLUGQAATPYNQMC2PTSNY3VFANCNFSM4KX5KBJQ>
.
|
Similar to the one discussed in publiclab/plots2#6501 we should have maintainers groups in IS to collaboratively manage different features of IS this would help in maintaining the library more efficiently, Features around which we can develop a team around includes:
core-maintainers:GOALS: Stability and optimization of the core library.
CURRENT PRIORITIES: Fix deprecated libraries. eg: readPixels and savePixels are actually not maintained and in fact, do not work at all for GIFs.
module-maintainers:GOALS: Increasing the number of modules, stability/optimization of existing modules. Ensuring that creating new modules remains easy and accessible and well documented. Developing and maintaining compelling use-cases for IS, as in database/gallery of important/cool sequences #1480.
CURRENT PRIORITIES: Increasing module GIF support and fixing bugs.
ui-maintainersGOALS: Stability and performance.
CURRENT PRIORITIES: Fixing UI bugs and perhaps refactoring some of the old, unmanageable code.
tests-maintainers:GOALS: Increasing test coverage.
CURRENT PRIORITIES: Increasing UI test coverage. Module and GIF tests are messy and decoupled, this needs to change as these tests are breaking unexpectedly.
cli-maintainers:GOALS: maintain existing features and expand test suite.
CURRENT PRIORITIES: completing initial CLI test suite and covering all basic usages
What do you guys think?
@publiclab/is-reviewers @publiclab/support @publiclab/mentors
cc: @jywarren
The text was updated successfully, but these errors were encountered: