Update README.md with Collection information #2
Conversation
Adds the information posted by @ZibbyKeaton in nodejs/evangelism#278 to the README.md. This will need some edits to update phrasing centered around Evangelism/individuals, but otherwise should be good to go.
There was a problem hiding this comment.
Overall this looks good, just a few comments.
I do have a bit of meta commentary, and a bit of a concern. This update doesn't give any indication of why someone should contribute. As someone who writes somewhat often and has had some work professionally published before, I know that getting something published can be a lot of work, something this README kinda confirms. That's fine, good writing takes effort, but what this README doesn't do is indicate why the effort is worth it in this instance (I assume that writers/editors aren't paid, right?)
I'm not saying it's something you need to figure out right this second, but it is something you should put some thought into because otherwise it could limit contributions.
README.md
Outdated
|
|
||
| Note: this team is overseen by the [Node.js Community Committee](https://github.com/nodejs/community-committee) | ||
| ## Purpose of Node.js Foundation Medium publication | ||
| The Node.js Foundation’s new Medium publication serves as a channel for the community to broadcast to a wide audience its views related to Node.js and its ecosystem. This may include: |
There was a problem hiding this comment.
nit: I would change "Medium" to be a link to medium.com
README.md
Outdated
|
|
||
| ## How to submit for consideration | ||
|
|
||
| - Please submit a brief summary and the topic of the post to `medium@nodejs.org` for consideration. The email alias reaches the review team consisting of Zibby Keaton, Sarah Conway, Tracy Hinds, Mikeal Rogers, Tierney Coren, Ross Kukulinski (with the potential to expand in the future). |
There was a problem hiding this comment.
FYI, if we list out who this email goes to, we'll need to be sure to keep it up to date. For example, Mikeal is leaving the foundation soon and will no longer be receiving these AFAIK.
There was a problem hiding this comment.
Would it be easier to maintain if the list of mailing list members were provided in a separate document & this section linked to that doc?
There was a problem hiding this comment.
I don't think so TBH. Neither of these are charter documents, meaning there's no extra hoops to jump through in updating this vs another document.
There was a problem hiding this comment.
I think we can drop this list - it is already out of date. I think a simple way to keep the reference is to say that it goes to members of the Node.js Collection Team.
README.md
Outdated
| - Other topics will certainly be considered, but it should be something of interest to the Node.js community | ||
|
|
||
| ## Quality | ||
| We are looking for posts that teach and provide value to our community. Contributions should include the meta-narrative that “Node.js is maturing and gaining widespread use in mainstream enterprises, while continuing to inspire amazing potential and creativity among the massive community using the platform.” Sub-domains and topics for the Medium page include: |
There was a problem hiding this comment.
I have some reservations about this section. First, the section does not seem to describe quality; rather, it appears to mostly focus on potential topic or tone. Second, while I agree with how the meta-narrative quotation summarizes the current stage of the Node.js' lifecycle, I'm not sure that it's in the best interest of the community or platform to require that articles "toe the party line." I think the Collection would be better served by focusing on tone/style here rather than prescribing a narrative.
For the sake of discussion, here's another stab this paragraph that
Tone and Content
We are looking for posts that inform, teach, experiment, and generally enrich our community. There's no hard and fast rule of what an article should or feel like; Node.js Collection articles should be as diverse as the community itself. Ideally, contributions should encourage readers to explore new ideas, dig deeper into old ones, and to inspire readers to experiment and tinker. Articles can cover any number of topics such as:
…
If you're passionate about something not listed above, please don't hesitate to submit your idea for consideration.
|
I really like @SVincent's updates to the quality section. I would keep the tips and guidelines section in there. @nebrius do you not think the benefit to the technical reviewers is enough or people that are looking to write something? We've had a lot of submission to this, so I'm not as worried about getting submissions, but if you think that would be helpful... What are some reasons why you have written in the past? Personally, I would image some would include that it's another great way to contribute to the Node.js community and it's really great exposure - this will be shared across the Node.js Foundation handles and we have over a half a million followers. Let me know what you think of this and we can add a "benefits to submit" section in here. I'm happy to own the task of updating the email list - I have to do this anyway as the Linux Foundation owns the alias and I can quickly edit the Medium doc. |
|
@ZibbyKeaton With respect to my tweaks, I totally agree with keeping Tips & Guidelines. My aim was to tweak the section to better fit with the rest of the document, not to obviate any other sections 🙂 |
|
@ZibbyKeaton see my answers below
To be honest, I don't think it's clear from the READMe what any of the benefits actually are. As someone who's been involved in the Node.s Foundation for some time, I certainly have my own opinions on what those benefits are (and there are some), but if someone without my historical context were to come along and read this, I suspect they would be left thinking "this is weird, it sounds like they want me to do a lot for them and I don't get anything in return." I'm not saying this is this case, but the README should do a good job of allaying those concerns. I should also point out that "doing this to benefit the community" is a misnomer. Most of the people who would make good reviewers are already doing a lot of things to benefit the community, and in practice we're so overworked that our value judgement isn't "does this help the community?" but rather "does this help the community more than the other 10 things I have to choose between such that I should prioritize this above those other 10 things?"
I may not be the type of writer you want to reach here, but I write for one of three reasons: 1) I'm writing for myself (e.g. publishing to my personal blog or some other platform where I have complete 100% editorial control) 2) I'm getting paid to write or 3) I'm writing for a charitable cause. FWIW I haven not actually encountered 3) yet, so all of my writing has been either for myself or I have gotten paid for it. I have a firm rule against writing for someone else if I'm not getting paid and it's not for charity. Node.js doesn't count as charity, so I won't write for Node.js unless I'm paid, directly or indirectly (FWIW I do get paid to work on Node.js in general, so this may not be an issue for me specifically).
I'm hope I don't need to tell you just how exploitative and problematic "writing for exposure" is. I would strongly recommend that you never use that word again when discussing writing for free. Node.js may not be perfect, but we do a lot of things right, and it's imperative that everyone involved in all parts of this project constantly thinks about how we contribute to making one of the best open source communities out there. "Writing for exposure" does the exact opposite of that because it reinforces predatory practices from other communities. |
README.md
Outdated
|
|
||
| ## How to submit for consideration | ||
|
|
||
| - Please submit a brief summary and the topic of the post to `medium@nodejs.org` for consideration. The email alias reaches the review team consisting of Zibby Keaton, Sarah Conway, Tracy Hinds, Mikeal Rogers, Tierney Coren, Ross Kukulinski (with the potential to expand in the future). |
There was a problem hiding this comment.
In terms of updating the review process, it should state
First bullet changed to "Members of the Node.js Collection Technical Review Team and Node.js Foundation PR team will review your submission in a timely manner and provide the green light to draft the entire article or provide feedback or direction.
Updated to the second bullet under "review process for original posts" - this should be taken out and changed to "Once the review team has made suggested edits, they will share all suggested edits with the author who has final sign off on content."
Add the following bullet: If the author feels comfortable, we would also like to list out the names of the technical editors of the post.
Updated Section to "Review Process for Created Medium Posts"
- If you are interested in becoming a technical editor, please file an issue.
|
@nebrius thank you for your responses. I've been thinking about this and I understand that you want to add in the “why,” but we are not experiencing any issues with submissions. Maybe this is something that we can focus on if we are experiencing issues with submissions in the future? We've been working on Node.js Collection since February and have had -- and continue to have -- a steady stream of articles coming in (approximately 5-6 per month). The Foundation marketing team provides a grammar copy edit, but are not technical Node.js experts. Initially, we asked the evangelism group to edit submissions for fact-checking and technical accuracy. However, we have had trouble getting technical Node.js experts to read, review and edit submissions (largely, as you mentioned, because a lot of folks are tapped out). Our fear is that something will be published that is technically inaccurate and not credible. This would be damaging to the community and the Foundation. After presenting our problem at a recent CommComm meeting, we brainstormed possible solutions. In that discussion, we decided that we would update our process doc. and outline some possible benefits to serving as a technical editor for Node.js Collection submissions. The benefits listed in our updated process doc. Were discussed as reasonable and hopeful useful benefits to offer to anyone who volunteered to serve as a technical reviewer (see below). Again, as for the benefits of writing for Node.js Collection, I believe people do it for a number of reasons. We do provide some reasons why one might want to write for the Collection in the guidelines that we created back in February, see here: https://medium.com/the-node-js-collection/introducing-the-node-js-collection-4d0d60e72a64. This post also lists the entire submission and review process. From the READMe standpoint, I believe @bnb is working on that and will largely base it off what has been created and our updates to this. I would simply be updating the guideline section that is already on the Medium publication based on the new review process and @svincents edits to the "quality" section as I think it's really well written. This new discussion is trying to solve the problem of not having enough technical reviewers. We’ve put in a PR to have the READMe updated - we requested that the url to our Collection be added. We also requested that an additional Tone and Content section per the suggestion from @SVincent. |
To be clear, I'm not pushing on this because I fear we won't get submissions, I'm pushing on this because it's the right thing to do. Creating works "for exposure" is exploitative and problematic, full stop, regardless of anything else. It doesn't matter if people are still submitting or not. Also to be clear, as I realize I may not have been clear on this before, I'm not saying we should add the "why" for people to submit in this PR, I'm saying we should add the "why" for people to review in this PR.
This is good stuff, and should be front and center in this PR. Remember, the purpose of this repository is almost entirely for recruitment reasons, so it's not just enough that the information exists, it needs to be easily accessible and presented in such a way as to convince people to review articles. Think of this document as an advertisement. |
|
@nebrius we will not be adding the creating work "for exposure" to any of our material. I was just riffing off the "why" someone might do it, but we will definitely not include this in any materials for all the reasons you mentioned above. And yes, let's make sure the "why" review is front and center. @bnb how can we help move this along? |
Addresses proposed edits by Zibby, Simeon, and Bryan.
|
@ZibbyKeaton I have addressed all edits proposed. If others agree, I'd like to merge this and we can move any further discussion into PRs/Issues to continue rather than blocking this further. |
|
Merged! ❤️ |
Adds the information posted by @ZibbyKeaton in nodejs/evangelism#278 to the README.md. This will need some edits to update phrasing centered around Evangelism/individuals, but otherwise should be good to go.