I've found a bug in your open source library but I'm not going to raise an issue to log it. Sorry.

I suspect many people think this but never say it. 

It comes down to one simple fact: I haven't got the time.

I know many people will be upset with me for saying this. I also know that I've been disappointed by others who have expressed or displayed this attitude themselves.

So, why aren't I going to report the bug/issue/problem I've found?

These aren't always the case but usually:

• I assume that what I've found is an edge case. (If it wasn't someone else would have logged this previously---I recognize that if everyone thought this nothing would ever get reported.)
• I don't expect it to get fixed. (This is often tied to it being an edge case.)
• I've already spent lots more time on this than I wanted to (can really afford to) so another unplanned task related to this doesn't feel like a good use of my time. 

Expanding on that last point, a good bug report takes time to create. It depends on the project and the issue but for something non-trivial, I've found this can often take me several hours.

If what I've found is trivial to explain and recreate then creating a bug report or issue is simple and I'll always try to create one.

BUT

If it's not simple to explain and recreate, creating a bug will likely be a waste of my time and effort. 

Creating a bug/issue doesn't help me with the project I'm working on. I've just created a workaround that works with the code I have now. 

If the issue is fixed in the project I'll need to spend more time verifying the fix and (possibly) removing the workaround I've had to use.

Having found a workaround that meant spending more time than originally planned, I'll have to spend more time creating a bug (& repro), and then possibly spend even more time verifying a fix and making any necessary changes. Stopping once a workaround is found is often very appealing.

But what about other people who may encounter this issue?

Yes, creating an issue for them to find may help them. If I can share a workaround then even better.

If not an issue, maybe a blog post explaining the workaround would be something faster to create. That way at least there's a document somewhere on the internet for others to find. Sadly, very few scenarios (or projects) warrant (or allow) a brief description of a problem and a workaround.

If my aim is to make the best use of my time to help others, documenting a workaround for an obscure edge case doesn't feel like a good use of my time. Surely there are things I could do that would help more people...

This situation isn't good for anyone.

I don't want it to be like this.

I wish quick, simple bug reports were acceptable. - Even just a brief description that could be expanded upon over time. However, a description without a simple reproduction is likely to get closed rather than left open waiting for more details.

If it was an open-source project, I'd be happy to create an issue that has a description of the problem and a workaround (or link to one if documented elsewhere).

Having detailed instructions on how to report issues including having requirements on creating/including minimal ways to reproduce an issue are appealing from the perspective of a maintainer but are offputting for a person who just wants to use the library/tool and doesn't have the time to create a detailed report. 

Or could there be something better?......

I don't have any answers. 😢

I just wanted to start documenting my thoughts on this subject. I expect to have a follow-up post to this, eventually.

As a project maintainer, I'd rather know about any problem, no matter how vague or seemingly lacking in details. Knowing that something's wrong is preferable to not knowing.

At best it might indicate a gap in the documentation.
At worst it means a vague issue remains open. Possibly indefinitely.

Admittedly, if I had millions of users and loads of vague issues being created I may think differently.

Let me try and be clear (although being very aware the people I've most upset will probably not make it this far before saying something rude about me):

• I want the tools I use to get better, add features, fix bugs, etc.
• If I can and if you make it easy, I will raise issues.
• If you make raising issues hard I'm much less likely to do it.
• I know you're busy and your time is valuable. So is mine.
• If you want to report an issue with one of my open-source projects, I'll happily take as much (or as little) detail as you can provide. The more detail you provide the more likely I am to be able to do something about it. But, I'd rather know there was a problem, even if it can't easily be recreated (yet!)
• I'm aware this approach may not apply to very large projects. (If only this was my problem.)

Thoughts? tweet at me

Are technical computer books supposed to make you laugh out loud?

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Honestly, I laughed out loud when I first read this.

Do you find manually retyping something (already in a digital format) less error-prone than copying and pasting?

Am I unusual in finding copying (& pasting) something being less likely to result in any potential errors than typing it myself?

I get that typing something yourself can help when you're learning something and want to be clear about what code you're adding and why. But, cutting and pasting has always been less error-prone than typing.

Questions to ask BEFORE asking a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) questions to ask yourself before asking a question:

1. Can I work out the answer myself?
2. Can I find the answer myself?
3. Will the person I'm asking know the answer?
4. Can they know the answer?
5. Will they be able to give me an answer if they know?
6. What will it cost them to answer?
7. Will this impact my ability or opportunity to ask other questions?
8. Will others want to know the answer?
9. Have others asked the question before? and what, if any, answer did they get?
10. Why isn't the answer easily/already available?
11. Is this the best time to ask? And if not, when is?
12. Have I been paying attention to what has been said already?
13. Other?

I know the above is a generalization, and it won't apply to all questions but is a helpful summary of the things to consider.

Not all are always relevant, appropriate, or useful, but all are worth considering before asking (or even answering) a question.

Questions to ask BEFORE answering a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) questions to ask yourself before responding when asked a question:

1. Do I know the answer?
2. Can I tell them the answer? (If I know.)
3. Should I tell them the answer?
4. Why do they want to know?
5. What assumptions do they have that have led to (or are evident from) the question?
6. Why do they think I know (or can get) the answer?
7. What will they do with the answer I give them?
8. Is there something I can give them better than the answer to their question?
9. What led them to ask this question?
10. Are other people likely to have this question?
11. Where else can I share this answer?
12. What type of answer are they expecting? (long, short, etc..)
13.  Other?

I know the above is a generalization, and it won't apply to all questions but is a helpful summary of the things to consider.

Not all are always relevant, appropriate, or useful, but all are worth considering before answering a question.

Forking Windows Template Studio

Windows Template Studio is a Visual Studio extension that helps developers scaffold Windows applications. 

I have a long, complicated relationship with the project and have been involved since its inception.

In June, Microsoft stopped funding the internal team who were working on it. I was told there were plans to continue the project with support from the community, but this didn't happen, and my emails have gone unanswered since then. 😢

Sadly, due to the way the project is set up and configured and because of the permissions I have, it's impossible to do anything significant within the existing repo.

So I'm taking it upon myself to do something separately.

Announcing Template Studio for UWP. (preview for VS2022 available now!)

Yes, it looks very similar to the Windows Template Studio wizard.

I'm starting by taking the UWP (and then WPF) capabilities of WinTS and breaking them into separate extensions that work with Visual Studio 2022.

WinUI(3) support will hopefully follow. As will support for creating apps that don't only run on Windows.

There's lots of detail I'll spare you from, but the bits most likely to be of interest are:

- My goal is to help developers now. (When Microsoft has left them in a state of uncertainty.)

- I'm updating the dependencies in the generated apps and will add other improvements and new functionality.

- I want to reduce the dependencies on developers installing the extension(s). You shouldn't need the capability to build any/every type of Windows app just to use the extension.

- I'm starting by focusing on the parts of WinTS that are less likely to be supported by Microsoft (UWP & WPF) if they do resume development (& support) of WinTS.

I'm open to contributing to the WinTS project again, but I'm not just sitting around while I wait.

- I'm doing this in a way that gives me the best opportunity to do other things with the code in the future. (Look at me being all mysterious. 😉)

- I'm taking the opportunity to make some much-needed (in my opinion) updates to the project and its internal dependencies. 

- It's not open source (yet), but I'm not ruling it out for the future. (I have many reasons that I'll save for another day/time/place.)

It's in preview now & I'd love feedback.

I'm updating (most of) my Visual Studio extensions to support VS022

Visual Studio 2022 has a lot of changes and new features.

The biggest one for me is that most extensions that supported earlier versions are not 100% compatible with this new version.

This means creating a new version of each extension that I want to be available on both VS2019 and VS2022.

Due to the way that I'm creating new versions (I have my reasons), it's possible that you can install two different versions on VS2019.

If you have multiple versions of an extension installed, you should uninstall the one that doesn't have "(2019)" at the end. If you're only using VS2022 then you won't see this.

For the most part, having both installed shouldn't be a problem but it might lead to some duplication of output or other strange behavior. I recommend you delete the older version. 

I haven't yet made VS2022 versions of all the extensions available yet. For the ones I haven't done yet, I have a (private) list for the order in which I will change them. Ones with more requests (especially from my GitHub sponsors) get top priority. Not all will be made available on VS2022 and some will take longer to do due to the complexities of migrating the code. If there's something you're curious about (want sooner), open an issue on the appropriate GitHub repository or send me a message.

I'm also using the process of reviewing and updating these extensions to add a prompt to try and encourage more of you to become a sponsor. Sponsor me any amount, either as a one-off on a recurring basis and I'll tell you how to make sure you never see this prompt again. Other sponsor benefits are planned for the future too. ;)

If you're curious, I might share how effective this is, but early feedback has been positive.

UnoConf (2021) - Quick reactions

UnoConf happened earlier this week.

If you missed it, you can watch it online.

There were some big announcements, including the launch of version 4.0. You can learn more from the video or read more in their official blog.

Rather than repeat what you can read elsewhere, I thought I'd share my initial reactions:

• As with UnoConf announcements in past years, it's impressive how much new functionality and how many new features have been added.
• It's exciting to see a push beyond just porting existing UWP/WinUI controls and adding new controls (as part of their new toolkit.) [Some of these look like they make some of the steps in the book redundant--and I'd like to find the time to investigate this.]
• It's exciting to see the Uno Platform team do things that push the wider ecosystem forward and provide broader functionality that Microsoft hasn't created yet. (Even though many assume that Microsoft should have.)
• It's also exciting that the team is trying to improve the way developers work by introducing their own framework. Hopefully, this will enable some developers to work more effectively and not confuse things. It'll be interesting to see how the message of "you can do and use everything you do on Windows and have it run everywhere" balances with a message that suggests "Uno Platform has their own way of writing code."
• It was sad to see the continued lack of clarity about the terms UWP, WinUI, & WindowsAppSDK. I know this is a problem caused by Microsoft and not the Uno Platform team. Still, by saying they're using WindowsAppSDK 1.0 and .NET 6, someone could easily be confused that they're still using UWP to build the Windows version of apps and have not yet switched to using WinUI3 (because they can't.)
• I also got the impression that there's a stronger push to encourage people to see the Uno Platform as an option when just building for the web. If this becomes a popular solution, it will definitely be good for the growth and adoption of the platform as web development is such a big market.
• While it's clear that adoption and usage are growing, there is still a lack of large apps that have been shipped (and can be talked about publicly as examples of what's possible). That the customer demos and testimonials from the event showed apps in progress or that are shortly to be released didn't help address this concern. Better than showing no customers, though.
• That 3rd party control vendors used the conference to (re?)confirm their commitment to the platform was also good. But, I got the impression they're waiting to see more platform usage (& their controls) before committing more heavily.

All in all, very positive, although there are a few things I'm cautious about. 

I'm keen to try some of this out and hear the broader feedback once more people have started using v4.0.

What are your thoughts from the conference?