I think a lot of it boils down to your goals with it, I'm personally very engaged with my user base and take pride in my communication and you may not value that over less work/more dev time. This is also for an internal tool but the audience is diverse (500+ devs, cybersecurity engineers, leadership, writers, etc), I stick with one set of release notes for a few reasons:
- One location, people who may fall into multiple categories (or none) don't need to check multiple places, users also know that all my communication will be via that page/they don't have to wonder if they're missing something
- As much as some detail doesn't matter to certain audiences, I find being able to give all the detail you want a user to know while maintaining readability to less technical audiences is a skill worth developing because the result is regardless of where your notes end up, the person will understand what's changed and why it matters
- Maintaining multiple versions leads to mistakes, at some point you'll leave out a detail to one audience that matters so letting the user mentally filter what they don't care about takes the onus to get it right 100% of the time off of you. I'll often categorize my changes by the section that had the change to help users with this.
- This is a personal preference and you touched on this one but it's just far less work, I've found it common in tech that people don't want to do things more than once or they'll automate it/look for shortcuts and this is no different. This isn't always a bad thing but getting release notes right means your users stay informed/use new features which is why we build them so I think it's worth putting my energy into doing it properly every time
I’m in a similar place with an internal tool. I have a two part changelog. In the first part, each release gets 50 words or less justifying its existence. This is ready to be copy pasted for management consumption. The second part goes into detail about what’s in the release, for technical people who care about those details.
Hi, Pletsch. The goal is Security Architect, however, I understand that this role requires extensive experience. In the beginning stages, I am willing to learn anything so long as it is in tune with an advanced learning curve.
I agree with the premise that report writers usually lack an ability to tell the story. It's tough though because I know a lot of SOCs and IT dept's will take any detail they can get if an incident happens in their own vertical and there is a lot of desire to help the community in IT/security culture.. but these reports really are for business partners more than anyone else and in that context, people could learn a lot by taking the advice into account.
The post does use cyber industry terminology inconsistently though, noted in another comment, and I fear that's going to make every technologist exit the page before getting the point.
This reads like someone who's coming out of CS, it's really hard to know this from outside the industry but these are two very different fields culturally. I interview for 10-20 cyber positions a year and a lot of your site doesn't pass the sniff test:
1.95% interview success rate and 400+ users? On effectively a new site?
2."Learn from industry leaders and seasoned FAANG professionals with real-world experience", like who? There are only so many cyber FAANG staff (and their time is very expensive) and not only do you not list backgrounds/who they are, you don't even list who you are on the about page
3. The hands on labs don't seem to exist? There are also plenty of sites you could point to that do this but I suspect you want the users for subscription $
I say all this because cyber is an industry based on trust and there's very little to trust about the site as it is.
Last thing I will add, LLMs in this field are struggling, you need a crazy amount of data to tune it properly and I fear you may end up doing more harm than good by having the model suggest made up things as good answers. I think a good path to solve this problem would be curating the questions for your background field (then hiring others for theirs) and having low-high value answers.
The article says Trellix but the same could be written about any EDR from a capability standpoint. To add to the staff's point about giving root access, and while that's more on Microsoft needing to get vendors out of the kernel, it shouldn't be a compromise users have to make.
With that said, I find myself agreeing with the mandate, if you're using university resources, they have a responsibility to protect those resources and EDR is table stakes these days.. but they also need to be providing any devices required for the job, allowing BYOD for restricted data makes an already tough environment to secure harder than it needs to be.
There is a complicating factor. Universities are not your average top-down hierarchies. While some aspects of the work do belong to the employer, other aspects are yours (or you PI's), and they may follow you to your next job. While administrative matters and sensitive data tend to belong to the university, everything you create as an academic is usually yours.
It's pretty common, particularly among researchers who do not handle sensitive data, to have a burner laptop for accessing university resources and personal devices for the actual work. Many people also use personal email addresses for work. Work email rarely survives changes in employment, making it too short-lived for many purposes.
Intrusive, malware-like "security" software running on user devices introduces undesirable security and privacy risks.
Moreover, universities should avoid the chilling effects of intrusive monitoring of faculty and student devices, as well as the potential legal liability.
A better solution is resource access revocation upon detection of bad behavior, with an administrative escalation path to manage false positives.
It gets mentioned at the end but service disruption really is the problem here. Reminds me of how quickly my govt (Canada) breaks strikes nowadays to avoid these disruptions.
I don't know if there's a way out of businesses that don't see the value of IT ignoring these risks (outside of legislation) but I hope we don't end up in a situation where bailouts are common/companies rely on govt intervention.
- One location, people who may fall into multiple categories (or none) don't need to check multiple places, users also know that all my communication will be via that page/they don't have to wonder if they're missing something
- As much as some detail doesn't matter to certain audiences, I find being able to give all the detail you want a user to know while maintaining readability to less technical audiences is a skill worth developing because the result is regardless of where your notes end up, the person will understand what's changed and why it matters
- Maintaining multiple versions leads to mistakes, at some point you'll leave out a detail to one audience that matters so letting the user mentally filter what they don't care about takes the onus to get it right 100% of the time off of you. I'll often categorize my changes by the section that had the change to help users with this.
- This is a personal preference and you touched on this one but it's just far less work, I've found it common in tech that people don't want to do things more than once or they'll automate it/look for shortcuts and this is no different. This isn't always a bad thing but getting release notes right means your users stay informed/use new features which is why we build them so I think it's worth putting my energy into doing it properly every time
reply