Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

001 Feedback from community #12

Merged
merged 3 commits into from
Aug 17, 2021
Merged

001 Feedback from community #12

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cb24152
Feedback from community
hadley Aug 2, 2021
29999f1
Re-build
hadley Aug 2, 2021
38a2eaa
Change status to accepted
hadley Aug 16, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 10 additions & 5 deletions 001-tidyup-process.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,15 @@ output: github_document
# Tidyup 1: what is a tidyup?

**Champion**: Hadley Wickham
**Co-champion**: ???
**Status**: Draft
**Co-champion**: Tracy Teal
**Status**: Accepted

## Abstract

For bigger architectural changes, particularly those that span multiple packages or are likely to affect larger number of users, we need a process to clearly document the problem, describe possible solutions, record our decisions, and collect feedback from the community.
This document proposes the **tidyup** as a lightweight way of navigating that process.

For now, tidyups can only be proposed by the tidyverse team, but we plan to open up the process to the wider community once we have more experience with it.
For now, tidyups can only be proposed by the tidyverse team at RStudio, but we plan to open up the process to the wider community once we have more experience with it.

## Motivation

Expand All @@ -34,6 +34,8 @@ To solve this problem, I propose a lightweight framework called a tidyup.
Tidyups follow a standard process that ultimately leads to an .Rmd in <https://github.com/tidyverse/tidyups>.
The following sections describe the basic process, the sections that most tidyups should contain, and a few notes about the scope of tidyups.

The goal is to reach [rough consensus](https://datatracker.ietf.org/doc/html/rfc7282): not everyone needs to agree on every detail, but there should be a general belief that the proposal is a net positive and all major concerns should be documented, even if not resolved.

### Process

1. **Propose**.
Expand All @@ -49,16 +51,17 @@ The following sections describe the basic process, the sections that most tidyup
Assume that everyone will at least skim the tidyup beforehand, but prepare to review the proposal with a focus on any parts that need extra discussion.
Soon after the meeting, review the meeting notes and update the tidyup with needed changes and clarifications.
If the proposal needs more discussion, repeat this step.
If the proposal is ready for wider discussion, merge the PR and continue.

(Depending on the complexity of implementation, the next two steps can be completed in either order)
(Depending on the complexity of implementation, the next two steps can be completed in either order.)

4. **Implement**.
Create a reference implementation in one or more PRs to the appropriate repos.
Update the tidyup with a link to the PRs in the implementation section.

5. **Community feedback**.
Ensure that you've rendered the `.Rmd` so it's easy for others to read.
Create a new issue that invites feedback, tag community members who's feedback might be particularly helpful, set a date when the review period will end.
Create a new issue that invites feedback, tag community members who might be particularly helpful, and set a date when the review period will end (at least two weeks later).
Once the review period ends, update the tidyup then close the issue.

6. **Final review**.
Expand Down Expand Up @@ -100,6 +103,8 @@ They're not compulsory, but where possible it's best to stick to the standard so

- **Open issues**: While proposal is in process, record open issues that require further discussion.

- **Unresolved questions**: Track unresolved questions and lingering concerns that did not get resolved in the PR, but need to be tracked for future discussion.

- **Implementation**.
Once available, provide a link to any PRs needed to implement the proposal.

Expand Down
31 changes: 22 additions & 9 deletions 001-tidyup-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,8 @@
# Tidyup 1: what is a tidyup?

**Champion**: Hadley Wickham
**Co-champion**: ??? **Status**: Draft
**Co-champion**: Tracy Teal
**Status**: Accepted

## Abstract

Expand All @@ -13,9 +14,9 @@ record our decisions, and collect feedback from the community. This
document proposes the **tidyup** as a lightweight way of navigating that
process.

For now, tidyups can only be proposed by the tidyverse team, but we plan
to open up the process to the wider community once we have more
experience with it.
For now, tidyups can only be proposed by the tidyverse team at RStudio,
but we plan to open up the process to the wider community once we have
more experience with it.

## Motivation

Expand Down Expand Up @@ -43,6 +44,12 @@ tidyup. Tidyups follow a standard process that ultimately leads to an
describe the basic process, the sections that most tidyups should
contain, and a few notes about the scope of tidyups.

The goal is to reach [rough
consensus](https://datatracker.ietf.org/doc/html/rfc7282): not everyone
needs to agree on every detail, but there should be a general belief
that the proposal is a net positive and all major concerns should be
documented, even if not resolved.

### Process

1. **Propose**. Start by raising idea in tidyverse slack or weekly
Expand All @@ -59,20 +66,22 @@ contain, and a few notes about the scope of tidyups.
prepare to review the proposal with a focus on any parts that need
extra discussion. Soon after the meeting, review the meeting notes
and update the tidyup with needed changes and clarifications. If the
proposal needs more discussion, repeat this step.
proposal needs more discussion, repeat this step. If the proposal is
ready for wider discussion, merge the PR and continue.

(Depending on the complexity of implementation, the next two steps
can be completed in either order)
can be completed in either order.)

4. **Implement**. Create a reference implementation in one or more PRs
to the appropriate repos. Update the tidyup with a link to the PRs
in the implementation section.

5. **Community feedback**. Ensure that you’ve rendered the `.Rmd` so
it’s easy for others to read. Create a new issue that invites
feedback, tag community members who’s feedback might be particularly
helpful, set a date when the review period will end. Once the review
period ends, update the tidyup then close the issue.
feedback, tag community members who might be particularly helpful,
and set a date when the review period will end (at least two weeks
later). Once the review period ends, update the tidyup then close
the issue.

6. **Final review**. Once both previous steps are completed, book
another tidyverse meeting for final sign off.
Expand Down Expand Up @@ -121,6 +130,10 @@ take in a new tidyup at a glance.
- **Open issues**: While proposal is in process, record open issues
that require further discussion.

- **Unresolved questions**: Track unresolved questions and lingering
concerns that did not get resolved in the PR, but need to be tracked
for future discussion.

- **Implementation**. Once available, provide a link to any PRs needed
to implement the proposal.

Expand Down