Closed Carreau closed 2 years ago
At the same time, using the blog for JupyterDay was super, super simple and allowed non-coders to do it with out using Github...
On Tue, Oct 20, 2015 at 1:45 PM, Matthias Bussonnier < notifications@github.com> wrote:
Right now, it is complex to add some infomations on the website as one need to write HTML by hand.
A good thing to try would be to investigate Jekyll that should allow to drop markdown files that would be converted to HTML by GitHub.
That would make pages like jupyter_days easier to maintain.
— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49.
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
The question was difficulty to find, and how to update information (during today's video meeting)
And usually one does not expect a blog post to be updated (a ghost static page might be better suited ?)
The Jekyll thing will anyway, not be only for this jupyter day (we won't have time to do it in 4 days).
Integrating the blog in the website would make navigation much simpler, and would allow sharing the navbar. There are not too many posts in the blog, so once we decide for what to use, everything would be easily migrated.
Integrating the blog in the website would make navigation much simpler, and would allow sharing the navbar. There are not too many posts in the blog, so once we decide for what to use, everything would be easily migrated.
Would also make thing much easier for review, and to collaborate.
Sidenote, I'm still unsure about Medium for newsletter.
Would also make thing much easier for review, and to collaborate.
👍
Yeah, I'm quite unhappy with Ghost/Medium/GoogleDoc/ having to actually send comment in email body and emailing back and forth.
I know there are "Non technical people" but I'm getting tired of the complexity of N workflow. I know we've only published a couple of newletter with that workflow, but it's reaching the limit where I'm going to drop it, unsubscribe and say no sorry I don't want to review like that.
We should have to send comments back in email. Medium allows very nice editing in their web app. Why would we do that...
On Thu, Jun 2, 2016 at 9:45 AM, Matthias Bussonnier < notifications@github.com> wrote:
Yeah, I'm quite unhappy with Ghost/Medium/GoogleDoc/ having to actually send comment in email body and emailing back and forth.
I know there are "Non technical people" but I'm getting tired of the complexity of N workflow. I know we've only published a couple of newletter with that workflow, but it's reaching the limit where I'm going to drop it, unsubscribe and say no sorry I don't want to review like that.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49#issuecomment-223350756, or mute the thread https://github.com/notifications/unsubscribe/AABr0FxdFecJC63BQ5jLr3a09MkWpen-ks5qHwiYgaJpZM4GSW2E .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
We should have to send comments back in email. Medium allows very nice editing in their web app. Why would we do that...
Because we receive emails asking us for feedback. So I respond with the medium I'm contacted with.
Matthias - sorry for the confusion and pain involved in this latest review.
For clarification: we aren't using ghost or google docs in our workflow anymore, and I didn't intend for you to make edits within an email. I posted an issue two days ago on the newsletter repo asking for review within Medium (with instructions on how to comment). I didn't get any replies and no comments were put on the Medium draft, so I emailed you and other reviewers.
Matthias - sorry for the confusion and pain involved in this latest review.
No worry.
The issue is there is close to 40 issues open per day on GitHub on the Jupyter org. And each of these issues can have many comments each day. So I (and I'm not the only one) cannot be subscribed to all the repository. [And that's just counting GitHub] So I (often) don't receive notification unless I'm explicitly mentioned on the GitHub issue. Hence I just missed this one. Feel free to tag people nag us after 24-48 H if we haven't responded,
Will do in the future, we're in the final process of testing this newsletter and can't take any more edits in the Medium post, we'll have to pick up the process for next time.
Will do in the future, we're in the final process of testing this newsletter and can't take any more edits in the Medium posts, we'll have to pick up the process for next time.
Well the cookie cutter think does not make sens. It's like saying, "you can start your car turn by with a key".
The "We recently introduced a package", also sounds "of course you know about this new things we already don't told you about". Which is a bad first sentence.
This is why I suggest we only have one technical editor. Coming to a group consensus on what makes a good sentence is a waste of my time.
I will send out a test preview and receive comments one more time and we can decide if it's good enough to send out. I'm having issues with the size of the image of the top so we can solve this issue in parallel with that.
Some clarifications about the newsletter workflow:
but everyone ignored it
I don't think ignored is the right term. It imply that people did not respond or act voluntarily. I, just never saw it.
We are not using Google Docs or Ghost for the Newsletter in any way. Just one tool - Medium.
I was not trying to imply that we are using these for newsletter, I was referring to the comment of sylvain about the blog, which is ghost. And the process of writing/reviewing something on Ghost is also a painful one, so we are using Google Docs for drafts.
I worked with Ana today to simplify the process even further by making Katie an Editor on Medium as well.
Thanks,
Ana and I talked about possibly moving to a monthly newsletter cycle because of the limited time everyone has for reviewing and editing the posts.
I would be happy with that.
In the future, requests for reviews should be emailed directly to people rather than posted as a GitHub issue - but the actual review can occur by those folks directly editing the post on Medium.
GitHub is still possible as long as people get pinged. The problem with last request is likely that nobody got notifications. And you can also assign multiple people on GitHub. I'm fine with mail too if you prefer it.
Hey all - I'd like to go ahead and move this to a monthly publication. Some of the biggest pains we've been experiencing would likely be alleviated by having more time in between publications. I would propose the next drop be June 15. We will have some time to refine/add to our current content prior to publishing June 15.
Newsletter 1: March 15 Newsletter 2: March 30 Newsletter 3: May 18 Scheduled Newsletter 4: June 15
Thoughts? I think postponing today's drop would make future monthly drops look more consistent. If at some point we have our flow down we can review whether going to bi-monthly makes sense.
@Carreau @ellisonbg @fperez @willingc @katiewhite360 @jamieshq - please see note about postponing this weeks newsletter and let me know if you have any concerns.
Sounds good to me
On Fri, Jun 3, 2016 at 11:34 AM, Ana Ruvalcaba notifications@github.com wrote:
@Carreau https://github.com/Carreau @ellisonbg https://github.com/ellisonbg @fperez https://github.com/fperez @willingc https://github.com/willingc @katiewhite360 https://github.com/katiewhite360 @jamieshq https://github.com/jamieshq
- please see note about postponing this weeks newsletter and let me know if you have any concerns.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49#issuecomment-223658282, or mute the thread https://github.com/notifications/unsubscribe/AABr0D4I4CyY-4oRVsvPgky60CGxRWtjks5qIHPPgaJpZM4GSW2E .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
Great idea @Ruv7. Monthly seems a better cycle for the long newsletter.
On Fri, Jun 3, 2016 at 12:17 PM, Carol Willing notifications@github.com wrote:
Great idea @Ruv7 https://github.com/Ruv7. Monthly seems a better cycle for the long newsletter.
- a lot! I'd always advocated for a monthly cycle, glad to see this. Thanks much!
Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail
The authoring / reviewing environment could be independent of the deployment.
Integrating the blog in the website would make the navigation in the website much nicer. Indeed, some of the links in the navbar send you outside of the website, which is not what you would expect.
If the Github workflow is too cumbersome for non-developers, we can still use another system for the quick iterations and reviews.
So to ask for review - should I send an email or put a draft in GitHub and tag reviewers in the post?
So to ask for review - should I send an email or put a draft in GitHub and tag reviewers in the post?
Go for the simplest for you for now. We're still bikeshedding. And you are doing a great Job !
For the newsletter, we should stick with doing all review on Medium itself, rather than email or Gmail.
On Mon, Jun 6, 2016 at 2:32 PM, Matthias Bussonnier < notifications@github.com> wrote:
So to ask for review - should I send an email or put a draft in GitHub and tag reviewers in the post?
Go for the simplest for you for now. We're still bikeshedding. And you are doing a great Job !
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49#issuecomment-224095047, or mute the thread https://github.com/notifications/unsubscribe/AABr0EYs2DWsNi1SnLF0sL-vUawab5aXks5qJJHrgaJpZM4GSW2E .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
ok, so would you guys accept a PR migrating all the content of the blog to the website?
ok, so would you guys accept a PR migrating all the content of the blog to the website?
let's wait on this one. We have a lot on our plate. And we would need to make sure we break the rss feed for our 756 readers.
I would like to see how the newletter goes and possibly migrate the blog to Medium entirely. Having the blog on GitHub makes almost impossible for non-technical staff to contribute.
On Mon, Jun 6, 2016 at 3:09 PM, Sylvain Corlay notifications@github.com wrote:
ok, so would you guys accept a PR migrating all the content of the blog to the website?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49#issuecomment-224104029, or mute the thread https://github.com/notifications/unsubscribe/AABr0OjfR2Pq0BcemyEJuUay0wp_n1X9ks5qJJqegaJpZM4GSW2E .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
I would like to see how the newletter goes and possibly migrate the blog to Medium entirely. Having the blog on GitHub makes almost impossible for non-technical staff to contribute.
The problem is that this does not address the navigation issue on the website.
Very true - but the same issue is also there for the docs.
On Mon, Jun 6, 2016 at 3:27 PM, Sylvain Corlay notifications@github.com wrote:
I would like to see how the newletter goes and possibly migrate the blog to Medium entirely. Having the blog on GitHub makes almost impossible for non-technical staff to contribute.
The problem is that this does not address the navigation issue on the website.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49#issuecomment-224108177, or mute the thread https://github.com/notifications/unsubscribe/AABr0CBkLwMsz7gIeO2aiODnelzVvSeAks5qJJ7dgaJpZM4GSW2E .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
I would like to see how the newletter goes and possibly migrate the blog to Medium entirely. Having the blog on GitHub makes almost impossible for non-technical staff to contribute.
And 3 out of 16 blog post are from non technical people. I'm ok making concessions for non technical people, but at some point it will start to annoy the core team because they can't do their work.
Very true - but the same issue is also there for the docs.
Yes, I think that the blog is the easiest to solve, then nbviewer then the docs.
We likely won't change nbviewer. For security/legal/confusion reason it should be on a separate doamain.
I am curious about each individual security/legal/confusion reason.
security
We have services on jupyter.org that require login, nbviewer is made for injecting user credentials. It's too risky to have both on same domain.
legal
Nbviewer does not host content. jupyter.org
does.
It's better to keep the 2 distinct. If we ever get a DMCA request it's "easy"[1] to refute.
confusions
Same as legal. Everything on jupyter.org
is likely "official". If we start to host things without domain and (slight) theme distinction, then everything looks official.
Sidenote, I still strongly things the nbviewer should be nbviewer.org
not nbviewer.jupyter.org
. Something we agreed upon and was never done.
[1] with all the precaution and quotes necessary
Then we should probably remove nbviewer from the navbar, if it is not intended to become part of the website. (I think the most convincing argument here is about what is 'official' or not)
@rgbkrk might have some opinion on the security issue mentioned here.
I'm confused as to what is actually being discussed here. I'm missing how the blog/medium, nbviewer, and the docs are related.
As for the blog vs. Medium, I don't think it's necessarily an either/or decision. Many businesses use both with content replicated/repackaged since they serve different user segments.
Perhaps to simplify things, the blog/Medium should be driven by the CalPoly team (Ana with her social media expertise; Katie with writing and interviews; Brian/intern team guiding design; I would be willing to do the tech review and ping Matthias, Sylvain, and the rest of the devs as relevant). Since folks are co-located it may simplify things at least for the next 3 months.
@willingc what I brought up initially is that a lot of the links in the navbar of jupyter.org actually bring you to a different website, which is very unintuitive. I was proposing to bring some of those in the jupyter.org website and remove others from the navbar.
Forgot - a while back Cameron made a Ghost theme for the blog that had the same nav bar as the website. He got it working, but there was no one to install it...
On Mon, Jun 6, 2016 at 8:00 PM, Sylvain Corlay notifications@github.com wrote:
@willingc https://github.com/willingc what I brought up initially is that a lot of the links in the navbar of jupyter.org actually bring you to a different website, which is very unintuitive. I was proposing to bring some of those in the jupyter.org website and remove others from the navbar.
- integrate the blog in the website. The deployment of the blogpost would imply a github PR but the initial review / iteration could happen on a different medium.
- integrate nbviewer in the website (this triggered another discusstion with @carreau https://github.com/carreau which you can see above)
- remove the link to the rtd hosted documentation from the navbar and put it elsewhere in the website.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyter/jupyter.github.io/issues/49#issuecomment-224156527, or mute the thread https://github.com/notifications/unsubscribe/AABr0EyxH1ftvMq1uNqohX2Ae72W7R1Hks5qJN7QgaJpZM4GSW2E .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
Forgot - a while back Cameron made a Ghost theme for the blog that had the same nav bar as the website. He got it working, but there was no one to install it...
Even if we have a similar theme, this lead to duplicate effort as each update of the main website content need to be replicated on the ghost theme.
I won't oppose to such changes, but in the end it's the kind of details where we'll lose afternoons of work to get all the things right. I already spent 2 days converting jupyter.org to jekyll to avoid synchronizing all page by hand, and I don't want to go through that again. Actually let's rephrase that: I have enough other things to take care of, I'll likely not have time to go and fix it.
I do understand that non-technical people might be annoyed and have difficulty with a jekyll-based website/blog, but at some point you have to consider that all of this is also a non negligeable amount of time lost for the the technical people as well.
For example, I do (most) of my blog writing in vim. And yes I do insert :w
when I'm writing in online text editors. Ghost is not awesome but at least it allows me to copy past markdown and see diffs.
So with Gost , I can copy past and use word-diff -U0
.
I cannot do that with Medium, example of the current future newsletter. I have to reread the full content each time to see if the change have been made. I have to click on all link to check they are the right one.
So I'm just making the request to weight each changes by considering all the factors and people involved. It's not because something look simpler at first sight for a single user that it is simpler and is the right choice.
@SylvainCorlay Thanks for the added context!
I strongly recommend leaving the Documentation link in the navbar. We get a reasonable amount of hits there. I wouldn't want to move that link until usability testing was done.
Would it make sense to keep a single documentation / install
item in the navbar. The jupyter.org internal page would give some basic information to get started and provide a link to RTD for more detailed information?
@SylvainCorlay I think we could find a solution consolidating the Documentation
and Install
items. I think it would be wise to proceed cautiously and user test any proposed combination.
Some of the user testing done last summer showed that users really struggled to find Documentation and Install when they were not explictly mentioned in the navbar.
Putting nbviewer on a wholly separate domain is a CYA, similar to how github uses github.io and a few other domains to deal with cross domain vulnerabilities that can prop up. Since nbviewer will render any notebook, we need to make the precaution.
nbviewer.org currently does a redirect to nbviewer.jupyter.org, someone has to do the ops necessary to migrate nbviewer.org to being a duplicate of the current nbviewer (can use same backing servers) before we make one the default.
Readthedocs did that a month ago
See #234 for an alternative proposal...
Rather than opening a new issue suggesting you not use Medium, I'm leaving a comment here. I'm no longer following the Jupyter blog because you write it on Medium and they require an account to read articles. I feel like that is against general open source principles and hope it is against the Jupyter principles too. Please consider hosting your blog somewhere with free and open read-access.
Just a note that I think @mankoff is referring to this banner / behavior:
@choldgraf roughly yes, but what I saw this morning was much larger and blocking - it wouldn't let me read the latest post about the SQL kernel. Apparently I've been to their site too many times (3x?) this month already.
Huh, for some reason the "you have 2 free stories left" notice only shows up for the recent SQL post, and not for any previous posts (for me, anyway). Is this a change that has recently happened in medium, or is it something specific to that SQL post 🤔🤔🤔
After doing some digging, I think this message is popping up because somebody clicked the "allow this post to be part of Medium's curated paywall" button. This is normally off which is why other posts don't have this problem. See https://help.medium.com/hc/en-us/articles/360018834314?source=post_page-----9549c5dcf551----------------------
It seems like the author can disable this following these instructions: https://help.medium.com/hc/en-us/articles/360018637634/ @SylvainCorlay do you want to get in touch with the author and see if they are able to do so? Otherwise many readers are probably going to hit a paywall limit
Right now, it is complex to add some infomations on the website as one need to write HTML by hand.
A good thing to try would be to investigate Jekyll that should allow to drop markdown files that would be converted to HTML by GitHub.
That would make pages like
jupyter_days
easier to maintain.