-
Notifications
You must be signed in to change notification settings - Fork 165
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
Improve User Feedback/Engagement (feature voting) #82
Comments
I'm +1 on all of these and think it's a good idea. Another note is that you can easily sort issues by the number of certain reactions as a vague approximation of what @chrisjsewell describes: https:/executablebooks/jupyter-book/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc For the "alternative discussion forum", I think an easy step could be to create a category in the jupyter community forum for this. I've found it to be an easier place for more free-form discussion and conversation than using either github issues (because they are best-suited to "closeable" and actionable topics) or chat rooms like Gitter (because they are harder to use for conversation that spans more than 1-2 hours or time) I think that a |
Yep, I think we should maybe then have a separate The pain point with EBP is that generally feature issues are currently spread/duplicated across repositories, i.e. to implement a feature in jupyter-book, it requires a feature implementation in markdown-it-py + myst-parser + myst-nb
The main solution here I guess, and for promoting the discourse site, is to use issue templates to "re-direct" people to the correct location |
Maybe we start out with
Yep - that's what we do in the jupyterhub issue template |
Cool, do you want to create this category then, and we can add links to it in the issue templates and CONTRIBUTING.md/SUPPORT.md |
Sounds good - do you think we should call it maybe @jstac / @mmcky / @AakashGfude / @najuzilu have thoughts? |
executable-books IMO |
executable-books sounds good to me. I also really like @chrisjsewell 's suggestion at the top of creating a way for users to share what they have created using myst/jupyter book. That's one of the things that https://bookdown.org/ does well. I suppose we can get people to share links --- and that would be a good first step --- although links don't provide the same visual feedback as bookdown's entry page. |
I think it'd be pretty easy to programmatically generate a nice-looking table of demo books. What's the action we'd like a user to take? Add an entry to a YAML file somewhere? A few things for inspiration:
|
|
Very cool! I wonder if we could just embed that in a page with some nice-looking CSS and have that be it? Though we'll probably hit the github GraphQL rate limit if a lotta people hit the page. Another thing we could do is to generate an updated list once a day or so, and host it in the website somehow. I do this kinda thing with jupyter-wide activity by generating notebooks and building books w/ them here: https://predictablynoisy.com/jupyter-activity-snapshot/ |
Yep that was the thinking
Good point, the limit is ~1000 (5000/<5 repos>) per hour, so shouldn't be an immediate issue (I just added sessionStorage caching though as a small mitigation) |
yeah fair enough - I'm +1 on optimizing for the rate limit another day after we've actually hit problems w/ it Note that I believe the rate the limit isn't "number of requests", it's something like "number of edges touched in the GraqhQL query, so it might be less than 1000?) |
Nah I've already checked (returning-a-calls-rate-limit-status) its cost=1 per request. |
how the heck was |
I had to kill a human to get it |
Just found out about the coming GitHub Discussions, seems like they will be a better alternative to discourse (in terms of integration), although I'm sure @choldgraf will not be happy with the expanding monopoly by Microsoft lol |
I have requested we be added to the GitHub Discussions beta: https:munity/t/can-one-apply-for-github-discussions-beta/121120/34?u=chrisjsewell |
hah I am definitely not happy with the Microsoft monopoly, I dunno why more people don't worry about this :-P I'm not going to die on this hill, though IME I've found Discourse to be a nice place for community interaction. We don't have to do what the broader jupyter community does. |
Its ok, but you just don't get the integrated links to Github code/issues/PRs/users etc. |
for sure - I think the question is what other kinds of features are missing between the two. In my experience the best parts of Discourse are the community management pieces, they give you a ton of knobs to tweak if you wish, and ways to influence the kinds of conversations that happen in the discourse forums. It's a much more complex thing than just "a place to have non-linear conversations" so I wonder how much GitHub Discussions will be able to replicate the same product |
Out of interest, what is an example of one such "knob"? |
a couple examples off the top of my head:
|
Currently, the main source of user feedback is via repository specific issues.
As the number of issues grow, e.g. in jupyter-book, this is not always the easiest to navigate.
A few thoughts come to mind:
Upvoting System
I think having a system for upvoting features might be helpful.
The idea is that people upvote on a feature by adding a thumbs up (👍) to the first comment of an issue.
These issues+upvotes are then counted autonomously by a git bot and output into a table somewhere, e.g. in the README or RTD docs
Examples of this is https://caniuse.com/issue-list (the github API code for this is here aozq/GitHubIssuesSortedByVotesPage#1) and https://vote.biglybt.com/,
all-contributors is also an example of a bot that pushes a table to the README
This could be done with the existing repository issues, whereby only issues tagged as
enhancement
would be assessed.But perhaps having a central location for this would be better, e.g. creating a
community
repository where issues should only be feature requestsThe text was updated successfully, but these errors were encountered: