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.

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

Issue forms/templates #12617

Merged
merged 3 commits into from
Aug 23, 2021
Merged

Issue forms/templates #12617

merged 3 commits into from
Aug 23, 2021

Conversation

benjyw
Copy link
Contributor

@benjyw benjyw commented Aug 20, 2021

For:

  • Bug reports
  • Feature requests
  • Adding a company to a public list of users

The driving goal was the user registration template, but it made it a bit weird, when opening a new issue, to have a template for that and not for bugs and feature requests. The user would have to click on a small "open a blank issue" link to actually file a normal issue. So this change also includes the bug and feature templates. Those are purposely simple though, and based on GitHub's suggested templates. No need to make bug/feature reporters jump through form hoops.

[ci skip-rust]

[ci skip-build-wheels]

  - Bug reports
  - Feature requests
  - Adding a company to a public list of users

[ci skip-rust]

[ci skip-build-wheels]
@benjyw benjyw changed the title Issue forms for: Issue forms/templates Aug 20, 2021
@benjyw
Copy link
Contributor Author

benjyw commented Aug 20, 2021

Template chooser renders as:

Screen Shot 2021-08-20 at 3 50 53 PM

@benjyw
Copy link
Contributor Author

benjyw commented Aug 20, 2021

User registration form renders as:

Screen Shot 2021-08-20 at 3 52 28 PM

@benjyw
Copy link
Contributor Author

benjyw commented Aug 20, 2021

Bug report renders as:

Screen Shot 2021-08-20 at 3 53 13 PM

@benjyw
Copy link
Contributor Author

benjyw commented Aug 20, 2021

Feature request renders as:

Screen Shot 2021-08-20 at 3 53 59 PM

Copy link
Contributor

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

.github/ISSUE_TEMPLATE/bug_report.md Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/bug_report.md Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/feature_request.md Outdated Show resolved Hide resolved
@cczona
Copy link
Member

cczona commented Aug 20, 2021

For the user registration form, I suggest emphasizing that the email address is not for publication on the website. Also, "registration" typically refers to things like registering for warranty support or other customer support. So I wonder if that title would be dismissed as "I don't need this", rather than "Sure, I'll help support Pants by doing this". What if the title is something like "Support the project: add your company to user.pantsbuild.org"?

@cczona
Copy link
Member

cczona commented Aug 20, 2021

I like that you included the docs and Slack. Might as well also add the blog, twitter feed, and YouTube channel.

https://www.youtube.com/channel/UCCcfCbDqtqlCkFEuENsHlbQ

@benjyw
Copy link
Contributor Author

benjyw commented Aug 21, 2021

I like that you included the docs and Slack. Might as well also add the blog, twitter feed, and YouTube channel.

https://www.youtube.com/channel/UCCcfCbDqtqlCkFEuENsHlbQ

I'd rather not, because those aren't really places for getting help, which is what the focus is on here. And since the "template chooser" is already quite busy, I think we should keep it to just the highest value things.

@benjyw
Copy link
Contributor Author

benjyw commented Aug 21, 2021

For the user registration form, I suggest emphasizing that the email address is not for publication on the website. Also, "registration" typically refers to things like registering for warranty support or other customer support. So I wonder if that title would be dismissed as "I don't need this", rather than "Sure, I'll help support Pants by doing this". What if the title is something like "Support the project: add your company to user.pantsbuild.org"?

Changed the text relating to the email address to emphasize this.

Changed the title to "Support Pants - List My Company on pantsbuild.org". The description and other text already references the Pants Users list.

[ci skip-rust]

[ci skip-build-wheels]
Copy link
Member

@stuhood stuhood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

.github/ISSUE_TEMPLATE/user_registration.yml Outdated Show resolved Hide resolved
.github/ISSUE_TEMPLATE/user_registration.yml Outdated Show resolved Hide resolved
# Rust tests and lints will be skipped. Delete if not intended.
[ci skip-rust]

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
@benjyw
Copy link
Contributor Author

benjyw commented Aug 23, 2021

User form now renders as:

Screen Shot 2021-08-23 at 1 10 38 PM

@cczona
Copy link
Member

cczona commented Aug 23, 2021

For the user registration form, the main purpose is to validate that the submitter is affiliated with the organization they're adding. Contacting them with questions can typically be done via the issue itself, and in the rare private case taken to DMs or email. (We don't care what address someones uses when discussing questions. Whereas, ensuring that the Who Uses Pants list is accurate is important.)

I propose that instead of asking for email address, we treat the form as Part 1 of 2, with Part 2 being that they send an email (empty is fine) with subject "verify" from their company's domain to an address at pantsbuild.org (verify@pantsbuild.org?) which would be monitored by several Maintainers via Google Groups. The issue would only be approved after a Maintainer has established that the domain for the new listing and the submitter match. Then the Google Group would be available as audit trail if anyone questions the accuracy of a listing.

@Eric-Arellano
Copy link
Contributor

That's similar to how PyPI was doing two-factor authentication restores: you'd email each other before the issue could be closed. It worked well!

@benjyw
Copy link
Contributor Author

benjyw commented Aug 23, 2021

For the user registration form, the main purpose is to validate that the submitter is affiliated with the organization they're adding. Contacting them with questions can typically be done via the issue itself, and in the rare private case taken to DMs or email. (We don't care what address someones uses when discussing questions. Whereas, ensuring that the Who Uses Pants list is accurate is important.)

I propose that instead of asking for email address, we treat the form as Part 1 of 2, with Part 2 being that they send an email (empty is fine) with subject "verify" from their company's domain to an address at pantsbuild.org (verify@pantsbuild.org?) which would be monitored by several Maintainers via Google Groups. The issue would only be approved after a Maintainer has established that the domain for the new listing and the submitter match. Then the Google Group would be available as audit trail if anyone questions the accuracy of a listing.

Yep, see screenshot.

@benjyw benjyw merged commit 7817286 into pantsbuild:main Aug 23, 2021
@benjyw benjyw deleted the user_page_template branch August 23, 2021 21:58
@illicitonion illicitonion mentioned this pull request Aug 30, 2021
illicitonion added a commit to illicitonion/pants that referenced this pull request Aug 30, 2021
* Clean up the config parsing code. ([pantsbuild#12678](pantsbuild#12678))

* [internal] `--generate-lockfiles-resolve` does not determine `PythonLockfileRequest` for unspecified tools ([pantsbuild#12692](pantsbuild#12692))

* [internal] Add missing `resources` targets for default tool lockfiles ([pantsbuild#12670](pantsbuild#12670))

* [internal] Reorganize lockfile code to no longer be in `backend/python/experimental` ([pantsbuild#12669](pantsbuild#12669))

* [internal] Test that default tool lockfiles work on macOS ([pantsbuild#12666](pantsbuild#12666))

* [internal] Improve the error message for stale/invalid lockfiles ([pantsbuild#12618](pantsbuild#12618))

* [internal] Rename `./pants lock` to `./pants generate-user-lockfile` and `./pants tool-lock` to `./pants generate-lockfiles` ([pantsbuild#12641](pantsbuild#12641))

* [internal] Only run macOS tests in CI annotated with `@pytest.mark.platform_specific_behavior` ([pantsbuild#12665](pantsbuild#12665))

* [internal] Test that Python tools work with all expected interpreter versions ([pantsbuild#12656](pantsbuild#12656))

* [internal] Factor out a helper rule for setting up `--resolve-all-constraints` ([pantsbuild#12630](pantsbuild#12630))

* [internal] Add links to changelog and Twitter in Pants PyPI project page. ([pantsbuild#12636](pantsbuild#12636))

* [internal] Update CoC with proper markdown + https links. ([pantsbuild#12637](pantsbuild#12637))

* GitHub issue templates ([pantsbuild#12617](pantsbuild#12617))

* Register subsystems and target types by backend/plugin. ([pantsbuild#12623](pantsbuild#12623))

* [internal] Sort input requirements for `LockfileMetadata` ([pantsbuild#12615](pantsbuild#12615))

* [internal] Expect lockfile metadata to be defined ([pantsbuild#12616](pantsbuild#12616))

* Simplify subsystem registration. ([pantsbuild#12620](pantsbuild#12620))

* [internal] Use constants for magic strings `<none>` and `<default>` for tool lockfiles ([pantsbuild#12613](pantsbuild#12613))

* [internal] Refactor `lockfile_metadata.py` to be more class-based ([pantsbuild#12611](pantsbuild#12611))

* Embrace that help strings are markdown. ([pantsbuild#12606](pantsbuild#12606))

* Stop fetching a lockfile request just to figure out the requirements digest ([pantsbuild#12607](pantsbuild#12607))

* [internal] Refactor MyPy first party plugins ([pantsbuild#12599](pantsbuild#12599))

* [internal] Refactor MyPy config file setup ([pantsbuild#12593](pantsbuild#12593))

* [internal] use `is_union()` rather than `union.is_instance()`. ([pantsbuild#12595](pantsbuild#12595))

* fs_util can use mTLS and ignore certificates ([pantsbuild#12586](pantsbuild#12586))

* [internal] Fix Pylint lockfile to actually be wired up ([pantsbuild#12590](pantsbuild#12590))

* [internal] Update lockfile TODOs with current state of project ([pantsbuild#12592](pantsbuild#12592))

* [internal] Check for lockfile staleness by using context's interpreter constraints, rather than global constraints  ([pantsbuild#12566](pantsbuild#12566))

* [internal] Refactor Pylint first-party plugins ([pantsbuild#12583](pantsbuild#12583))

* [internal] Fix Pytest and IPython to check for stale lockfiles ([pantsbuild#12582](pantsbuild#12582))

* [internal] Do not cache lockfile generation ([pantsbuild#12674](pantsbuild#12674))
illicitonion added a commit that referenced this pull request Aug 30, 2021
* Clean up the config parsing code. ([#12678](#12678))

* [internal] `--generate-lockfiles-resolve` does not determine `PythonLockfileRequest` for unspecified tools ([#12692](#12692))

* [internal] Add missing `resources` targets for default tool lockfiles ([#12670](#12670))

* [internal] Reorganize lockfile code to no longer be in `backend/python/experimental` ([#12669](#12669))

* [internal] Test that default tool lockfiles work on macOS ([#12666](#12666))

* [internal] Improve the error message for stale/invalid lockfiles ([#12618](#12618))

* [internal] Rename `./pants lock` to `./pants generate-user-lockfile` and `./pants tool-lock` to `./pants generate-lockfiles` ([#12641](#12641))

* [internal] Only run macOS tests in CI annotated with `@pytest.mark.platform_specific_behavior` ([#12665](#12665))

* [internal] Test that Python tools work with all expected interpreter versions ([#12656](#12656))

* [internal] Factor out a helper rule for setting up `--resolve-all-constraints` ([#12630](#12630))

* [internal] Add links to changelog and Twitter in Pants PyPI project page. ([#12636](#12636))

* [internal] Update CoC with proper markdown + https links. ([#12637](#12637))

* GitHub issue templates ([#12617](#12617))

* Register subsystems and target types by backend/plugin. ([#12623](#12623))

* [internal] Sort input requirements for `LockfileMetadata` ([#12615](#12615))

* [internal] Expect lockfile metadata to be defined ([#12616](#12616))

* Simplify subsystem registration. ([#12620](#12620))

* [internal] Use constants for magic strings `<none>` and `<default>` for tool lockfiles ([#12613](#12613))

* [internal] Refactor `lockfile_metadata.py` to be more class-based ([#12611](#12611))

* Embrace that help strings are markdown. ([#12606](#12606))

* Stop fetching a lockfile request just to figure out the requirements digest ([#12607](#12607))

* [internal] Refactor MyPy first party plugins ([#12599](#12599))

* [internal] Refactor MyPy config file setup ([#12593](#12593))

* [internal] use `is_union()` rather than `union.is_instance()`. ([#12595](#12595))

* fs_util can use mTLS and ignore certificates ([#12586](#12586))

* [internal] Fix Pylint lockfile to actually be wired up ([#12590](#12590))

* [internal] Update lockfile TODOs with current state of project ([#12592](#12592))

* [internal] Check for lockfile staleness by using context's interpreter constraints, rather than global constraints  ([#12566](#12566))

* [internal] Refactor Pylint first-party plugins ([#12583](#12583))

* [internal] Fix Pytest and IPython to check for stale lockfiles ([#12582](#12582))

* [internal] Do not cache lockfile generation ([#12674](#12674))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants