Closed walshbr closed 5 years ago
walshbr
commented
6 years ago Note - there are some errors in the build due a different submission, so the lesson isn't currently rendering. I'll take a look at that in a bit and see about resolving those so that the lesson is viewable. In terms of beginning the review process for this, I'll take a look and aim to get initial comments back by the end of the week @drodz11. Then I'll send it out for review to a couple folks.
amsichani
commented
6 years ago happy to debut as reviewer on this, if it helps!
walshbr
commented
6 years ago Thanks @amsichani - will keep in mind when I look for reviewers!
@drodz11 I just finished an initial pass through the text. I had to make a few changes to get the lesson to build, so just be aware that your directories will look a little different. I moved the lesson inside the /lessons folder, and the images directory has to match the lesson name. So I modified the images directory accordingly. Let me know if you have trouble finding anything.
It looks like this would be a really useful addition to the lessons that we have. The most substantial revisions I recommend are at the end. I think the lesson needs a case study video that will give the piece some narrative and ground the different commands you're introducing in a use case relevant to the likely readers of the piece. That will really help make this look more like a lesson and less like documentation. At this point, I'd recommend you make the following changes before we send it out for review, because those changes would change the text in the second half a lot. There are also some notes here for general and local comments as well. Let me know if you have any questions and what you want to set as a tentative timeline for getting these in!
[x] paragraph 1 - here and throughout, you should use the relative links for Programming Historian lessons rather than giving the full link. I saw this come up in a few places. That helps ensure that future modifications to the site are easier to make. For example - https://programminghistorian.org/en/lessons/creating-apis-with-python-and-flask should instead be /en/lessons/creating-apis-with-python-and-flask
[x] Introduction comments more generally - I think this a good introduction. It’s a bit more lengthy and embedded in the critical conversation than our lessons usually are, but I think that’s fine. I had two thoughts. The first is on proportions. The critical conversation bit slightly outweighs the notes about the technology itself. It might be worth adding a couple sentences to even them out, since the technology is the actual focus here. A second note - I would move the learning objectives to either be s part of the introduction or immediately follow them.
[x] “Additionally, a basic understanding of audiovisual codecs and containers will also be useful to understanding what FFmpeg does and how it works.” - is this necessary information? after reading further I think it is, and I think adding some sort of basic information relevant to the text would be helpful.
[x] learning objectives - I would be more specific with “learn several useful commands.” What are the commands? What exactly will people be doing? That will help someone looking at a glance tell if the lesson they’re looking at will be immediately useful to them.
[x] “Note: New versions of FFmpeg are released approximately every 6 months. To keep track of these updates, follow FFmpeg on Twitter or through its website.” - this might be worth pausing over. What things tend to change? Is the whole lesson going to be obsolete in six months? What are some ways we can ensure that the lesson is as stable as possible? I’m not as familiar with FFmpeg as you are, so those really are honest questions that I don’t know the answer to.
[x] p 5 - add a link to the homebrew instructions.
[x] “brew install ffmpeg --with-sdl2 --with-freetype --with-openjpeg --with-x265 --with-rubberband --with-tesseract” - probably worth glossing some or all of these so that the reader has some sense of what they’ve just installed.
[x] “To upgrade your installation” - am I right in thinking that this is an optional step for users who have already installed ffmpeg (it was required for me) ? or is this something that should be done prior to installing? Either way, you should mention the software versions and dependencies used in the lesson in the introduction. Given your note about how much versions change, is this likely to be a step that breaks things?
[x] Other installation resources - it is worth giving a couple sentences as a gloss on what these two links are.
[x] Testing the installation - ffmpeg 4.0.2 is the one that installs when run on 8/7/2018. Might be worth updating the lesson to the latest version at time of writing, at least. The formatting of the terminal output here is difficult to parse because markdown is getting rid of your linebreaks. I’ll ping Matt to see if he has any thoughts.
[x] Code examples - here is the part that you could use the most substantive revisions I think.
[x] First, I think you’ll want a case study to make this something other than a rewrite of documentation that might be found elsewhere. Rather than pointing to the Blender Foundation video, do you have a video that you could walk through in what follows? That would require modifying the code blocks that follow so that they match the case study. A case study would have a particular object or video that you focus on, but it would also entail thinking about the process you’re asking the reader to go through. What will be the result? As is, the lesson moves through some commands that are all really useful, but there is no real sense of build or narrative. That sort of thinking will help make this more than documentation. So you might ask, “what will readers start with? what will they end with? How can I explain each step along the way in a way in which they can see what they can do and why they might want to do it?” For example, some lessons start with a dataset and wind up with a visualization they do a bit of analysis with. The Audacity lesson you link to starts with an audio file and manipulates it to turn it into a podcast. Even it requires shifting the particular set of commands the lesson covers, a case study will help the lesson read better, and it will also help give people a reason to read it.
[x] Second, early on you suggest that readers should have some background knowledge in certain areas described like codecs or containers. I think as written the lesson actually requires this, as the terms and concepts are deployed without much explanation. I would use the case study described in the last paragraph as a way into the concepts and actually describe them in the lesson itself. For example, in paragraphs 19 and 20 - what are codecs/containers? can you give more information about what they are and offer some situations in which a digital historian/humanist might need to do such things?
[x] paragraph 21 - “This is useful if you are interested in examining these components discretely or performing some kind of specialized analysis.” This is another instance in which giving more of a description might help. What kind of analysis is possible? Keep in mind that the readers here might be coming to find out exactly that.
I think much of the second half will change, so I didn't focus too closely on that - I can read it again when you send in your revisions. Let me know if any of that is confusing or if you'd like to discuss further! This looks to be a great addition, and I'd be excited to work further on it.
drodz11
commented
6 years ago @walshbr Hi Brandon, thank you for the quick turnaround and thoroughness of this feedback. I will start going through these revisions and recommendations this week. Can we set a tentative re-submission date as Aug 31? I will let you know if I have any questions or need clarification as I work through these. @amsichani Anna-Maria, looking forward to hearing from you as well! Thanks and looking forward to working on this more!
walshbr
commented
6 years ago Yep Aug 31st works! I'll make a note. Let me know if you run into any issues.
drodz11
commented
6 years ago @walshbr Hi Brandon, so I've gone through and implemented the first round of changes based on your initial comments. Please let me know (or point me to) the procedure for uploading the new version for further review. Thanks very much!
walshbr
commented
6 years ago Thanks, @drodz11. The procedure is the same - you can just upload the updated files to this repository. I'll take a look, and if things look workable I'll pass them along to reviewers to check out. The only thing I'd note in terms of procedure is that I had to move some things around in order to put your materials in the correct place. So you'll want to make sure you're working with an updated copy of the repository and upload your materials to the following locations:
https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images/introduction-to-ffmpeg https://github.com/programminghistorian/ph-submissions/blob/gh-pages/lessons/introduction-to-ffmpeg.md If you have any assets to add you'll put them here - https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets
Let me know if you have any questions!
drodz11
commented
6 years ago Thanks @walshbr! The complete second draft and new image files should all be where they're supposed to.
walshbr
commented
6 years ago Awesome thanks! I'll take a look in the next week or two and get back to you as soon as possible.
walshbr
commented
6 years ago I haven't forgotten about this @drodz11 - hoping to get to it this week.
drodz11
commented
6 years ago @walshbr sounds good and no problem at all, I figured the start of the semester was going to be a tough time. Thanks very much for checking in.
walshbr
commented
6 years ago I had a chance to take a look at this @drodz11. Thanks for addressing a lot of the concerns that I had last go around! I think this is getting there. A few small things -
As for the second half where you’re implementing the commands with the case study. I think this is getting closer. I appreciate the extra text in each section that starts to get towards the genre we’re after. I think one thing that could help this is a different case study, one that is relevant to historical research (and so more relevant to the genre our lessons usually work in). The one you’re using I suppose could be useful, but I think there might be a better one out there. The case study should show us why we care about the commands. It will help most if the case study has something interesting about it, and there might be other videos that you could sink your teeth into more easily. Is there anything useful or interesting to know about the metadata? About the way colors are used or the visualization? Right now you point to external projects as proof that the commands are useful. That’s great, and I think you should keep it. But I think in a perfect world you would be able to also describe the results that you get from the case study as you're going.
A good formula to follow in each section might be something like
Right now you’re looking good on the first two sections but not the third. And of course, not all commands will lend themselves super well to analysis (the codecs stuff, for example). But hopefully you get the idea. The third section that gives just a couple thoughts on each command as you’re using it (and what the command can tell you about the clip) doesn’t necessarily need to be long. But it will help pull this away from feeling like documentation and more towards something that could be useful for a digital historian.
So in short - a clip for the case study that is more relevant for digital historians could help. If you need help with ideas for clips that might give you more to sink your teeth into, the Internet Archive might have some good options - https://archive.org/details/movies. You can search by history or politics, which might be the ticket. I’m happy to give feedback if you’re having trouble finding one or if you wanted to bounce ideas off me before going through the work of processing the file again.
And in terms of linking the sections, it might be worth thinking about the case study not just as a thing that is poked in different ways but also something that is building through the sections. In the Audacity lesson, this meant that each command and method was working towards a finished podcast at the end. Here, you might think about a use case that would link all these pieces together. What things need to happen in sequence to achieve a particular result? How could you fill in the sentence “By the end of this lesson you will have produced X…” and put it at the top next to your learning goals? I could imagine the end result being a visualization, and then you walk the reader through each step along the way to get there. The pieces are all there, they just need a little narrative thread.
Hope this helps! And sorry this took me a couple weeks to get back to you. Happy to take a look again after you've made these changes.
drodz11
commented
6 years ago @walshbr Thanks, Brandon, again, for the thorough and productive feedback.
Your comments make sense and I think highlight something I also struggle with as a newishly minted academic librarian coming from the film and AV preservation world: making what I do/materials I work with relevant and useful to the practices of digital scholarship. It's a new and technically complicated arena, but putting this tutorial together is proving to be a challenging and useful exercise in getting my head wrapped around it.
I think going with other source material is a good first start to making the whole thing more cohesive and less like documentation. Going to take the time to cull through IA and see what I can put together. I may circle back with more granular questions along the way, although it may be a few weeks as I am traveling at the end of this week. At the very latest I will shoot for another update by Oct. 15.
Re: the initial three suggestions - I will add a bit of info to the installation error line, as for the other two I think the re-work of the article will probably resolve them.
Thank you again!
walshbr
commented
6 years ago @drodz11 - I totally understand, and I think the lesson is heading in a really productive direction. I'm totally happy to respond to any questions you might have, and Oct 15 sounds like a good goal. I'll make a note to check back in around that time if I haven't heard anything. Looking forward to reading the next pass!
drodz11
commented
6 years ago @walshbr Hi Brandon, I've taken some time to test out some different ways of approaching this tutorial in an effort to make it more cohesive/results-driven/etc and with a more specific focus on historical research and analysis. Before I start a full-on re-write, I wanted to offer an outline and see if you could provide any feedback. Here's what I got:
For this tutorial, we will be taking an archival film called Destination Earth as our object of study. This film has been made available by the Prelinger Archives collection on the Internet Archive. Released in 1956, this film is a prime example of pro-capitalist, Cold War-era propaganda produced by the American Petroleum Institute and John Sutherland Productions. Utilizing the Technicolor process, this science-fiction animated short tells a story of a Martian society living under an oppressive, Communist-like government and their efforts to improve their industrial methods. They send an emissary to Earth who discovers the key to this is oil refining and free-enterprise. We will be using this video to introduce some of the basic functionalities of FFmpeg and analyzing its color properties in relation to its propagandist rhetoric.
Here I will walk users through uploading the .csv files they created to plot.ly to visualize the color data on a graph. The first excerpt encompasses a montage on Communist-like Mars and presents a bleak view of their society employing a very limited color palette. The second excerpt, a similar montage on Earth, espouses the greatness of the oil industry and capitalism, uses a much more vibrant, broader color palette. The point here is not just that these two sections have different colors present in them, but that the pro-capitalist rhetoric of the film is tethered to the use of color. Capitalist society is depicted as vivid and variegated while non-capitalism is depicted bleak and relatively monochromatic. Below is a graph that demonstrates the different ranges of median hue values in both sections.
Changing to summarize this new case more specifically, and also offering a method for doing this kind of analysis on a larger set of videos. For instance, if one wanted to do similar analysis on all the John Sutherland films in the Preminger Archives, I will provide a BASH script to create .csv color data files for all videos in a given directory.
I hope this paints a somewhat clear picture of the new structure and content of the lesson. Please let me know if you have any questions and any feedback is very much appreciated.
walshbr
commented
6 years ago This sounds like a good rewrite to me! I think the example will give you more to work with and more stuff to discuss as you work with the various functions. I think that you'll have a good case for how the message of the propaganda is reflected the aesthetics of the video. And ffmpeg gives you an opportunity to work with and measure that aesthetic content from a technical perspective.
drodz11
commented
6 years ago @walshbr Thanks for the helpful feedback! Will start re-working and still shoot for another draft by Oct 15.
drodz11
commented
6 years ago @walshbr Hi Brandon, just uploaded a new, complete draft along with a new set of images. I will be looking forward to your feedback, but heads up that they are closing our library at FSU for a week in light of looming Hurricane Michael, so depending on how all that shakes out I may be somewhat off the grid for a bit. Hopefully we don't get hit too bad though. All the same wanted to make sure I got this up. Take care and thanks!
walshbr
commented
6 years ago Thanks so much! I'll aim to take a look at this soon. Hope you and everyone else there stays safe!
walshbr
commented
6 years ago This looks great @drodz11. I think the changes you made help this to track a lot better for digital historians, and there is more a sense of narrative to the lesson. I have a number of things below, but they’re almost all very small. Of the recommendations below, I only had two or three suggestions for adding sentences and one point about plot.ly that would need some thought. The rest should be pretty quick.
I'm good with this after these things, and I’ll start working on reviewers for this while you push up these changes if that works for you. Then you can ping me here whenever you’re ready for people to take a look?
drodz11
commented
6 years ago @walshbr Thanks for the close-read and thorough response! All makes sense and I think should be pretty straightforward to implement. Still playing some catch-up after the hurricane (FSU/Tallahassee fared all right, thankfully) but will hope to have this review-ready by early next week. As always, very grateful for your productive commentary.
walshbr
commented
6 years ago No problem! Take your time. Just ping me when you're ready to go. I'll take a look for some reviewers before then.
drodz11
commented
6 years ago @walshbr New draft with the last round of edits has been uploaded along with updated images. Let me know if anything is amiss.
walshbr
commented
6 years ago Thanks @drodz11 - you're so quick! Looking for reviewers now, and I'll ping here when I have some folks.
walshbr
commented
5 years ago One reviewer will be @jjromphf. Working on a second! more soon - B
drodz11
commented
5 years ago @walshbr oh awesome! Josh is a good friend of mine, we used to work together at the George Eastman Museum. One of the sharpest AV/DH folks around.
jjromphf
commented
5 years ago @drodz11 What a small world, Dave! I can't wait to take a deeper look at this, it looks awesome. I knew we'd be collaborating again soon.
walshbr
commented
5 years ago Got another reviewer! @tcari will be taking a look as well. I'll make a note to check in by the end of November if I don't hear back from the two of you. - B
walshbr
commented
5 years ago @tcari and @jjromphf - my reminder went off to check in on the review process here. If you need more time to share your review just let us know!
jjromphf
commented
5 years ago I think this lesson really hits the mark in terms of tone, scope, and technical detail. Having come to it after both @walshbr and @drodz11 have already made substantial edits, I have to say that it's in very good shape and that my suggestions are relatively minor. I think that the lesson successfully demystifies FFmpeg while still leaving lots of opportunity for exploration beyond the lesson itself. I think it's challenging enough for those with some experience with bash but friendly enough for complete beginners. If it's alright with you Dave, once it's published I'd like to use it for my DHSI course. Anyways, here are some small suggestions:
[x] p 2 - References to both "transcoding" and "re-encoding" are mentioned throughout the lesson. Perhaps you can define transcoding up here: "These kinds of processes, such as editing, transcoding (re-encoding) ..." and just stick with "transcoding" throughout the remainder of the lesson?
[x] p 8 - You may also want to mention that you can run brew options ffmpeg to see what additional features are available. These options tend to change as the formulae get updated, i.e. some codec libraries like libvpx are included by default now but they didn't used to be.
[x] p 10 - You could mention that most common Linux distros (Ubuntu, Fedora, Arch-Linux) have their own package managers already installed with ffmpeg packages available. These builds can vary, however, so Linuxbrew could be useful to ensure that the build is the same regardless of which flavor of Linux the user has.
[x] p 11 - Here you mention that FFmpeg offers downloadable binaries and source code on p 11, but you may want to add an additional line about the static builds under the "get the packages" header. They offer pre-compiled ffmpeg, ffprobe, and ffplay binaries for Linux, Windows, and OSX that users can unzip / untar without the need for a package manager. Just ignore this suggestion if you've already considered it, because using the binaries is still not particularly easy considering you either have to move them to a directory that's already in your PATH, or add their directory to your PATH, or use them like path/to/ffmpeg-binaries/ffmpeg -i blah.mov out.mp4.
[x] p 44 - In the sentence "a very common and highly-portable combination of codecs and container that is practically identical the .m4v" I think you just need to add "to" before "the m4v".
[x] p 46 - I really like how you break down the commands into their constituent parts. In the case of the codec (-c) flags, you may want to consider a different choice of words on the bullets describing the audio and video codecs, where:
-c:v libx264 = copy the video stream to the H.264 codecis somewhat misleading as the -c:v copy parameter used on -p 49 / 50 actually copies the stream, whereas the above command will transcode it. Perhaps you can switch it to something like "transcode the video stream with the H.264 codec".
[x] p 67 - I'm not sure if it's necessary or not, but perhaps the overlay filter (2nd to last bullet) may require some additional explanation, particularly the w/h (overlay width and height) and W/H (main input width and height) variables.
[x] p 75 - Typo - "dynanic" should be "dynamic".
[x] p 79 - Not sure how much we're assuming the audience already knows about bash, but should the use of the redirection operator (> destEarth_Mars_hue.csv) to pipe the output to a csv file be explained? I know it's not a bash lesson but it may be a little confusing to some since it doesn't show up anywhere else.
[x] p 92 / 93 - This is in line with the question above; would it be helpful to break down that bash for loop into its constituent parts like you do for all of the FFmpeg commands?
walshbr
commented
5 years ago Thanks @jjromphf! @drodz11 - let's wait until we get the second review from @tcari before you make any changes at this point. We can discuss anything that needs discussing at that time and then move on to the last phase of revisions.
drodz11
commented
5 years ago @walshbr will do! @jjromphf thanks so much for for feedback, incredibly insightful and helpful. And I'd be honored to be included in your coursework! Also greetings from AMIA!
tcari
commented
5 years ago This lesson does an effective job of showing how applying new kinds of DH analyses to film might deepen scholarship and generate diverse methodologies for the field. There are strong goals running through this lesson, and someone could easily skim the first couple sections based on their background knowledge.
I thought the inclusion of the web browser version of FFmpeg was especially useful for those who are unsure of whether this is a program they will use consistently. After I had stepped through the tutorial on my computer, I briefly went to the videoconverter.js version to try it out. You might consider specifying that this version does not (to my knowledge) allow one to participate in your lesson and underscore that it is a way to become more familiar with FFmpeg commands. To that end, it might be useful to move this paragraph under the “Prerequisites” as a space for those coming to this lesson to play around or perhaps at the end of the “Basic Structure and Syntax of FFmpeg commands” section.
There was a nice balance between explanation and activities throughout. In terms of the prerequisites, I did find myself wondering exactly how much background in running command-lines you believe necessary. I do a lot of work in film production and postproduction, so everything about how this lesson manipulates film is familiar to me, but I only foray into my computer’s Terminal occasionally.
If you would like to make your lesson a bit more user-friendly to people who are familiar with command-lines, but do not use them frequently, I have a few suggestions for you.
It can be hard to tell when Terminal is done installing or running something, so you might consider just adding a line about how this should take some time.
Until we hit the section “Viewing Basic Metadata with FFprobe,” everything that we have done to step through the lesson has entailed copy and paste. All of the next sections are a bit different and require some manipulation.
In p 26 I think it might be useful to highlight the fact that you have to put in your particular file path for the video like you do around p 20. Then, every time you write “destEarth.ogv” people will know to always include the whole path. Likely it will look much more like “/Users/Guest/Documents/destEarth/destEarth.m4v” and not just the file name.
In general, I think you’ve done an excellent job making these commands really clear, but perhaps there is a way to differentiate what gets copied exactly and what will have to be particularized by the user. Again, if you want your audience to have familiarity with FFmpeg commands, then this should not matter.
Some minor suggestions/ comments: p 1 – “humanists can investate” spelling. p 2 – “Adobe Premire” spelling. p 3 – “seperating audio” spelling. p 19 – “every ffmpeg command” – you might want to capitalize FFmpeg for consistency. p 24 – You might consider using the word “folder” instead of “directory.” p 37 – The sentence that begins with “It isn’t necessary to get” becomes a little hard to follow. You might break it into two sentences. p 42 – I thought this was a really solid explanation of why these exercises are useful. p 46 – “compadibility” spelling. p 47 – “lets” -> “let’s” p 48 – “will likely be useful if you hope to this is kind of analysis” -> “hope to use this kind of” p 61 – I thought this paragraph makes a strong case for why this lesson/ method is useful. p 67 “embeded” spelling (embedded). p 70 “embeded” spelling. p 75 – “how dynanic" spelling. p 84 – “the ciruclar graticle” spelling.
I enjoyed stepping through this lesson, and I think it will be a wonderful addition!
walshbr
commented
5 years ago Those all seem pretty straightforward and like good advice to me. @drodz11 - let us know if there is anything you'd like to discuss further before making revisions? Otherwise, we ask for revisions to take place in four weeks - would that timeline work for you? If we're good to move forward I'll consider the review period closed. Thanks to both of you for your great reviews!
drodz11
commented
5 years ago @walshbr 4 weeks sounds good to me. We'll set the deadline at Dec 31. @tcari and @jjromphf thank you so much for these great comments. I will start working through these soon, if I have any questions I will ping you here, but let me know if you'd prefer something else.
drodz11
commented
5 years ago @walshbr Just uploaded the final version of the lesson based on @jjromphf and @tcari 's feedback. Let me know if there is anything else needed on my end. Thanks so much to you all for your work on this, it has been a truly enjoyable and edifying experience. I'm looking forward to getting this lesson translated into Spanish once it is up and I'd love to talk more about being involved as a reviewer for future PH projects or other ways of contributing. Thanks again!
walshbr
commented
5 years ago Sounds good @drodz11 - I'll try to take a look this week. Thanks for being continually ahead of schedule!
walshbr
commented
5 years ago @drodz11 - just a note to say that I think this all looks great. I've done a final copyediting read, and I made a few purely cosmetic grammatical changes. I'll do one last read through and run the code blocks once more just to be safe, but I think we're good. Was just talking to our managing editor, and we're going to aim to publish this in the week after the new year for maximum visibility. Thanks for all of your work! I'll let you know if anything comes up, but otherwise no news is good news.
drodz11
commented
5 years ago @walshbr Thanks very much! Happy holidays and New Year!
drodz11
commented
5 years ago @walshbr Just wanted to check-in. I know this is a busy first-week for a lot of folks and we're coming out of a couple big conferences, but any updates appreciated. Thank you!
walshbr
commented
5 years ago @drodz11 - I've got things ready to go on my end, but we've changed how the publishing process works from a technical standpoint. So I just need answers to a couple questions from our technical lead before I can make the thing go live. Sorry for the delay!
drodz11
commented
5 years ago @walshbr No apology necessary! All understood. Thank you for the update and looking forward!
walshbr
commented
5 years ago Getting closer @drodz11! Ok @alsalin - you should be good to go for using this as a dry run of the new publishing guidelines. I'll be on slack today and tomorrow if you wanted to talk it through. The files you need to move should be all in this repo:
lessons/introduction-to-ffmpeg.md images/introduction-to-ffmpeg/ - (all the stuff in here) gallery/introduction-to-ffmpeg.png gallery/originals/introduction-to-ffmpeg.pg
And then the bio you'll need for the ph_authors.yml file on the main repo should be this:
- name: Dave Rodriguez
team: false
bio:
en: |
Dave Rodriguez is an audiovisual archivist, curator, and filmmaker. He is currently Resident Librarian in the Office of Digital Research and Scholarship at Florida State University.Let me know how it goes and let me know when you're ready to merge the pull request so that I can tweet and add it to the twitter bot.
walshbr
commented
5 years ago @drodz11 do you want us to refer to you as Dave or David? Just noticed we used Dave in one place and David in another, but the system wants us to be consistent. After that we're good to go! Assuming I hear back from you I'll aim to publicize and publish Monday morning.
drodz11
commented
5 years ago @walshbr apologies for the delay, I was out of town and w/o a computer over the weekend. Let's go with Dave across the board. Thanks very much!
walshbr
commented
5 years ago We're live @drodz11! Thanks so much to @tcari and @jjromphf for reviewing. I've scheduled out several tweets for this over the next week. Thanks for your hard work all - let me know if you notice anything now that the thing is live. But as for this ticket we can consider it closed 🎉
The Programming Historian has received the following tutorial on 'Introduction to Audiovisual Transcoding, Editing, and Data Visualization with FFmpeg' by @drodz11. This lesson is now under review and can be read at:
http://programminghistorian.github.io/ph-submissions/lessons/introduction-to-ffmpeg
Please feel free to use the line numbers provided on the preview if that helps with anchoring your comments, although you can structure your review as you see fit.
I will act as editor for the review process. My role is to solicit two reviews from the community and to manage the discussions, which should be held here on this forum. I have already read through the lesson and provided feedback, to which the author has responded.
Members of the wider community are also invited to offer constructive feedback which should post to this message thread, but they are asked to first read our Reviewer Guidelines (http://programminghistorian.org/reviewer-guidelines) and to adhere to our anti-harassment policy (below). We ask that all reviews stop after the second formal review has been submitted so that the author can focus on any revisions. I will make an announcement on this thread when that has occurred.
I will endeavor to keep the conversation open here on Github. If anyone feels the need to discuss anything privately, you are welcome to email me. You can always turn to @amandavisconti if you feel there's a need for an ombudsperson to step in.
Anti-Harassment Policy
This is a statement of the Programming Historian's principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.