Home Creators Posts Import Register Favorites Logout
haven't archived this post yet. have a subscription? use the importer!

Content

The twentieth episode of a monthly live broadcast for Patrons which aired live on November 16th 2018.

Read More... 

(cross-posted for your convenience)

Files

Previews only

OctoPrint On Air #20

The nineteenth episode of a monthly dev log/Q&A session about all things OctoPrint for my Patrons on Patreon which aired live on November 16th 2018. My Patrons can submit questions to answer during the Q&A session via a Google Form before and - usually ;) - also live during the broadcast via the chat. Expect more videos like that roughly on a monthly schedule. If you want to attend the live broadcast and ask questions beforehand or live on air, consider becoming a Patron on Patreon and selecting one of the corresponding perks - that will also help me with continuing to work on OctoPrint full time, which I love doing! OctoPrint's webpage: https://octoprint.org Community forum: https://discourse.octoprint.org Patreon: https://www.patreon.com/foosel ---- Links related to this episode: My interview with Tom: https://www.youtube.com/watch?v=qytk8_JpYyQ ---- What have I been up to 00:01:30 Short vacation 00:02:03 Interview with Tom 00:02:35 PyCon.DE 00:04:17 1.3.10rc1 & 1.3.10rc2 00:07:12 A word on release candidates and feedback on them 00:13:09 Anonymous Usage Tracking What are the next steps 00:21:02 1.3.10rc3 & stable 1.3.10 release 00:22:58 Everything currently on the backburner Q&A 00:25:44 "What have you printed lately? We always see your software work but not your print work." 00:29:04 "Do you have a Prusa MMU2, or one on order?" 00:30:08 "The 3D printing community has very deep links to makerspaces and fablabs. Are you part of a makerspace/fablab near you? How would you respond if you were invited to give a talk and/or workshop about OctoPrint plugins?" 00:31:44 "I've heard some angry grumblings from a couple of Redeem (Replicape) developers that GCode is a less than ideal way to send commands to a printer. I tend to disagree, but I was wondering what you think of the GCode language in general?" 00:29:37 "Do you feel that the latest drive to educate and protect users from themselves, with regards to OctoPrint instances being opened up to the public internet, has been, or will be effective?" 00:47:16 "Why does the ui need to reload after I click download of an uploaded g code file" 00:50:28 "Do you know how new multimaterial product like Palette from Mosaic will work with OctoPrint?" 00:51:25 Some words on public access to the usage statistics Wrap-up

Comments

Jimmy Payne

Hi Gina, Do you think it would help to have a bug report form that people can fill out on the the octoprint website which includes required information such as detailed description, steps to reproduce, expected behaviour, browser version etc. At the company that I work at, we implemented a page of this type so front end users could easily check which browser they were using via browser detection. I know this isn't completely reliable but the results have been fairly good. I think all it would require is some simple form validation and browser detection. The idea is basically that the end user has a form to fill out that requires detailed information about the problem they are having which has solid information about browser, release that they are running, extensions etc that generates a text based content that they can use to submit github issues.

Jonathan Charnas

Thanks Gina! Would've loved to join in & listen live, but work's been a bit crazy the last month or two and on a weekday I couldn't watch the stream. There's likely to be some private messaging coming your way regarding a plugin workshop in a month or two. Jon

foosel

The problem with this is that I'd need a) a service to upload this stuff to (with the rat's tail of GDPR fun attached), b) some way to establish a back channel since often I do have additional questions, so just a simple "here are the logs, have fun" isn't going to work either. Github would in theory work, in practice however that would require an existing log in session of the user. I can't do that against the OctoPrint instance though for technical reasons (unknown endpoint in local net), so I'd need at least a proxy service, so back to item 1. I've spent a lot of time thinking about all this in the past exactly for this reason, but so far haven't found a way that wouldn't become its own project, even with additional administrative overhead.

foosel

Happens :) Had to do it on a weekday this time and have to admit that it was kinda nice having it during my normal working hours instead of doing forced overtime on a weekend, so I might do this from time to time, but the goal is to try to mostly stick to saturdays again in the future ;)

Terrain4Print

The system described sounds like a service desk. User submits ticket. Maintainer asks for more information. User responds. Ticket is resolved. A quick googling reveals for instance Freshdesk.

foosel

I'm aware of service desk software ;) The problem - apart from that stuff centering more on customer service and not on the technical details of bug tracking - is that most of that stuff either a) costs a lot of money or b) a lot of time to administrate. Which brings us back to the administrative overhead. This is a one-woman-show, I don't have admins I can just tell "hey, setup and maintain a service desk please" and I also don't have anyone but me I can tell "yo, monitor that and do first level support" - and I'm already in way over my head with the tasks I have to juggle. And "Maintainer asks for more information. User responds." - the latter part is already a challenge today on Github and in the forums. I'm somewhat doubtful it would be different in service desk software.

Jimmy Payne

I'm not sure the way I conveyed my idea was completely clear. So here it is. There would not be any need to set up any service desk or anything like that. The idea is just to set up a form on the octoprint website that requires certain information that is critical to submitting accurate bug reports. This would be linked in README.md under ##Bug Reporting/Submitting issues as an example. The form would just help users collect vital information for submitting a github issue and generate some text content that the submitter can use for their issue submission; essentially helping people submit the required information to submit an accurate bug report. IDK about the GDPR stuff. Yeah maybe that stuff might be an issue. I'd be happy to implement this. I'm not sure why this would be so difficult to implement. You have the open source community to help you implement stuff like this right?

foosel

Ah. Sorry, I thought you were suggesting something automatically sending information. Sure, a form like that could be done easily. But I'm not sure it would help much because the ticket form already pretty much is a questionaire for people to fill the blanks in. Granted, it's all a big prefilled text blocked put into the description area. One could try if a HTML form that makes that a bit more readable might improve things. Of course that leaves the question on how to get people to actually find the link in question. People already don't find (or ignore?) the link to the contribution guidelines, even though it's linked to from the README ("For information about how to go about submitting bug reports or pull requests, please see the project's Contribution Guidelines.") It could be added to OctoPrint's footer of course. But you also want people to check if the issue isn't already reported. Github recently introduced a feature that might help there (duplicate checking), but still... I'd be happy to experiment though, so if you want to translate the current bug reporting template into an HTML form with a bit of JS magic that then spits out a fully filled out form that people can just copy-paste, I'd be happy to test this out a bit and see if it improves things in any way!