Around the time I was starting as community manager, we had suggestions to start time-stamping the demos, and I think that has been a helpful exercise for everyone.
At the start of the year, we had suggestions to group the demos into user-focused and dev-focused, as well as to make an effort to group the running order into a logical sequence. I think this is also good practice and where we can, we do.
For a while now, we have added redmine tickets so that anyone who is interested can explore more information about this feature.
Last demo, we started adding the version number of Foreman/Katello where the demoed item can be found (with a caveat that things change).
All of these changes originated from feedback from Foreman demoers and the community around Foreman. I think that all are positive and all are in the spirit of getting as most out of the demoes as possible.
Starting with demo 101 (I’m almost finished ) I will also start writing a summary and include this on the demo topic along with the timestamps. I have heard feedback that some people do not like to watch the demo. While I would love if people watched the demo and also asked questions/ felt comfortable giving feedback and opinions while live, I understand that we all have different styles, and also adding summaries might help a wider group of people access the demo.
Over the last two demos, I have received feedback that viewers would love if the person who is demoing could provide context before they begin the demo themselves. Some people do this naturally, while others launch into the technicalities. Personally, I think that giving some context to your demo, for example, a brief summary of the workflow or the user story that this helps to progress, would be a great benefit.
I want to ask what you think about this and also if you have any other ideas/feedback for improving the demo?
I think we need less details and more information about the context. My personal rule of thumb:
Introduce viewers into the problem like they are seeing Foreman for the first time.
Explain the feature/change briefly, include motivation, what you considered and why it is designed the way it is designed.
Briefly show the functionality and skip details.
Prepare long actions in advance and only show results.
Do not treat demos as a showcase that something does work, we are professionals, we know that we deliver features and bugfixes which do work. Sort of
I was also wondering if it feasible to group headline major release features into special demo that would be closer to the release date so we would actually use the demo to create some noise during launch windows.
I agree with everything you’ve said, and like your suggestion, except for this:
As someone who tries to keep up to date with the new changes in the project, I must say that I do appreciate the details. It’s the only real time I get to watch exactly what is required for Foreman users. It helps me when I’m trying to contribute some docs or guide someone in the community. It helps me keep up project knowledge.
Another point on this - I harbour some hope that I’ll be able to convince some docs person to cover the demos, so we have whatever is demoed also documented and available in master. I think that a walkthrough of the details is useful for this.
I get that for some people the demo is treated as part of, for example, Agile done-done-done criteria. In a previous job, we were forced to demo each and everything to a project manager before a sprint could be considered “done”. This included proving it worked.
While in general, I agree with you that it isn’t necessarily the purpose of this demo, I still don’t have an issue with a demoer making an effort to display a successful end state.
I would absolutely love to host an event like this Like a “release party” essentially.
This was more of my thinking when I am preping for demos myself, these statements are extreme for myself as I tend to overshoot my planned time. By skipping details I mean rather irrelevant details, I guess I struggle to articulate what I mean.
Typical example would be filling out the whole New Host form field by field on the demo. I would rather show the form, maybe fill in the relevant field (subject of the demo) and then skip over to already created host. That’s what I meant.
Exactly, and I feel like this is not the right demo for this kind of content. While many managers watch demos from several companies involved in the development of Foreman and Katello, the moment features are presented on our community demos these were typically already discussed and closed via our internal scrums. At least this is the typical workflow in my teams.
Also, software engineer showing off a feature that is apparently working never meant anything to me. This can be tricked, there are cheats and development setups are usually quite special. Now, a quality engineer putting his/her name on a sign-off document THAT is a proof I can accept
But hey, if there is anyone who wants to show something does work for the first time, well, good luck to you and totally do it!
We can have a demo of features targeted for the release once RC1 is available. This should help users and contributors to test the features and we have at least 28 days to fix something which is reported while testing the RC1 release. However sometimes release notes are not updated with upcoming features by the time of RC1 and looking at redmine and pull requests can be time consuming to come up with features for demo.
For the actual “release demo” - this shouldn’t be an issue.
Can I help with this at all?
For example, if I write summaries of the demos, which are technically content on master a lot of the time, could we take what I write for release notes for RC1?
) I will also start writing a summary and include this on the demo topic along with the timestamps. I have heard feedback that some people do not like to watch the demo. While I would love if people watched the demo and also asked questions/ felt comfortable giving feedback and opinions while live, I understand that we all have different styles, and also adding summaries might help a wider group of people access the demo.