You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a discussion to categorize and work through the existing PR's.
First, I want to address how frustrated I am by the amount of open PR's and how long they have been open. It takes something to clone a repo, understand the inner workings, find/fix the issue, add documentation explanations/examples, add test cases, and then finally put together a PR... only to be ghosted.
It sucks and it's a feeling shared by the other maintainers. I don't want to excuse this behavior because as a collaborator, I am responsible. I want to talk through the challenges to set standards that can be used to expedite this process for current and future PR's.
Reasons to remain open
Some PR's may require something to be added to the library. If a PR has none of the below labels associated, that means that it needs to be reviewed by the collaborators to determine the scope and impact of the proposed PR.
Pending TS - v5 introduced TypeScript as the basis of the library and so older PR's may require refactoring.
Pending tests - Some PR's may require tests to ensure that existing or new behavior isn't broken in the future.
Pending docs - Some PR's may require a documentation update.
Pending changeset - Some PR's may require the changeset command to be run to properly attribute and describe the updates in the changelog.
Pending reply/revision - Some PR's have outstanding requests for changes or unresolved concerns that could make this a candidate for a future release.
I understand that many authors likely will have no desire to pick up code they wrote for a project several years ago perhaps for a professional code environment that they may no longer be involved in. Those in the community looking to contribute can pick up these orphaned labors of love (or necessity) with these labels to push these forward.
Reasons to close
Closing PR's feels bad as it means that something someone cared enough to write code for may interpret their efforts and concerns as a rejection. It's avoiding the difficult conversations that's put this repo in this situation, and for the library to move forward it will have to make difficult and perhaps unpopular decisions.
Here is an in-exhaustive list of reasons that a PR might be closed:
Introduces regression issue or breaking change.
Code changes do not address underlying issue or would be better made part of a larger set of changes.
In regards specifically for feature requests, A Select component has 70+ props without including variants, styles, method apis or its sub-components. Every new prop adds another layer of complexity which in some cases can be solved without changing the underlying library.
Adding prop "x" should fall under one of two categories:
The feature cannot be implemented without rewriting the internal methods
The feature resolves common boilerplate
The vision for this library is to create a public repo for users to add new behavior/components with hooks so that creating a rich experience can be done easily through composition instead of adding unnecessary complexity to the core internals. We will get there, but it's important we tidy up and give closure to the authors of the PR's that are written.
I encourage any closed PR that has a feature request to be added to the discussion area in the ideas section. Enough upvotes would likely mean that it would help others and that when we are in a position to encapsulate and add that to some common repo or even as an examples or "how to do 'x'" kind of thing which is something that Jed is very keen on.
So we comb through the PR's and my goal is to have every existing PR with a "pending" label or closed by the end of the year.
Thank you everyone for your undeserved and highly appreciated patience.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is a discussion to categorize and work through the existing PR's.
First, I want to address how frustrated I am by the amount of open PR's and how long they have been open. It takes something to clone a repo, understand the inner workings, find/fix the issue, add documentation explanations/examples, add test cases, and then finally put together a PR... only to be ghosted.
It sucks and it's a feeling shared by the other maintainers. I don't want to excuse this behavior because as a collaborator, I am responsible. I want to talk through the challenges to set standards that can be used to expedite this process for current and future PR's.
Reasons to remain open
Some PR's may require something to be added to the library. If a PR has none of the below labels associated, that means that it needs to be reviewed by the collaborators to determine the scope and impact of the proposed PR.
I understand that many authors likely will have no desire to pick up code they wrote for a project several years ago perhaps for a professional code environment that they may no longer be involved in. Those in the community looking to contribute can pick up these orphaned labors of love (or necessity) with these labels to push these forward.
Reasons to close
Closing PR's feels bad as it means that something someone cared enough to write code for may interpret their efforts and concerns as a rejection. It's avoiding the difficult conversations that's put this repo in this situation, and for the library to move forward it will have to make difficult and perhaps unpopular decisions.
Here is an in-exhaustive list of reasons that a PR might be closed:
In regards specifically for feature requests, A Select component has 70+ props without including variants, styles, method apis or its sub-components. Every new prop adds another layer of complexity which in some cases can be solved without changing the underlying library.
Adding prop "x" should fall under one of two categories:
The vision for this library is to create a public repo for users to add new behavior/components with hooks so that creating a rich experience can be done easily through composition instead of adding unnecessary complexity to the core internals. We will get there, but it's important we tidy up and give closure to the authors of the PR's that are written.
I encourage any closed PR that has a feature request to be added to the discussion area in the ideas section. Enough upvotes would likely mean that it would help others and that when we are in a position to encapsulate and add that to some common repo or even as an examples or "how to do 'x'" kind of thing which is something that Jed is very keen on.
So we comb through the PR's and my goal is to have every existing PR with a "pending" label or closed by the end of the year.
Thank you everyone for your undeserved and highly appreciated patience.
Beta Was this translation helpful? Give feedback.
All reactions