Silverlight 5 is finally released!  Congratulations to the team for getting through some of the toughest parts of finishing a product and validating with customers.  It’s been a pretty crazy year for the Silverlight team and this is a really good release for the product bringing some solid features to the platform for folks to leverage in building their apps.

In addition to the platform having a release, I was really pleased to see an update to the Silverlight Toolkit, which has been one of the most popular things almost every Silverlight developer/application uses.  If you didn’t know where to get things, here’s some links for you:

• Silverlight 5 Tools for VS (requires SP1)
• Silverlight 5 Toolkit
• Developer runtime for Windows (32 bit, 64 bit) and Mac OSX

Rather than enumerate all the good features that were finished from the RC/Beta, you should head on over to listen/watch Pete Brown’s presentation on the Silverlight 5 release overview.  He also has a post about the release enumerating in short form (with links to tutorials for some of the key features) on his blog.

What I think is really cool is also the amount of effort put into the Silverlight Toolkit for this release.  The one large thing of note is the extensions to enhance your 3D development experience in Silverlight 5.  David Catuhe has a post outlining in great detail some of the 3D extensions included in the toolkit.  You should really go check out his post.  Scrolling to the bottom I was really surprised/impressed to see a set of 3D samples included to help you understand how to use this feature:

• Bloom – uses the Content Pipeline and post-processing effects
• CustomModelEffect
• Generated geometry – how 3D models generated by code
• Particles – c’mon, who doesn’t like a particle generator!
• Platformer - while not 3D it appears, it is a complete game with levels
• 3D Animation
• Skinning – shows skinning a character using the content pipeline

I mean, wow, great stuff David! 

I hope you all enjoy the release of Silverlight 5 and kudos to the team for getting it out the door. Go download the bits and start building awesome stuff.

It seems like a daily question I’ve been answering lately when working on internal email discussion groups and folks report an issue, my initial response is: what build combination are you working on? 

As a part of my job, I like to ensure the fastest resolution (or awareness depending on how you look at it) to issues that affect our product.  This involves staying on top of ‘latest bits’ as we call them.  Every morning I come in and install the latest Windows build as well as the latest Visual Studio build.  We have an automated Hyper-V environment that makes it easy to get the initial Windows builds up and going and then I selectively apply VS on top of that.

So if it sounds so simple, why do I ask that question to people that ask?  Allow me to show you a few diagrams.

The above is a *snapshot* of just a few of the branches that affect the tools area that I work on.  This is not representative of the entire branching structure, which is huge. 

NOTE: This diagram is automatically created for you from Team Foundation Server…you select the branches of interest and it visualizes for you.  There is also an awesome feature to track changes which I’ll note below.

The red box items make up the different teams working to bring together the holistic view of some of the core developer experiences.  Since they aren’t *just* working on my stuff, nobody can live in a single branch together in harmony.  You can see that the spread of varying levels of branches required to get something working is pretty broad.  And merge (we call them RI/FI) processes are on different schedules and managed to reduce conflicts as much as possible.  The above is just one piece of the puzzle – the developer tools.  Windows has a similar ancestry view we have to deal with:

The red boxes here are basically other Windows teams that we need stuff from to get our product working as well.  These RI/FI process go through many, many checks and if any regressions, they don’t allow merging, which can cause issues if you are waiting on a fix to come to your branch!

So the answer to whether something should work at any given time during development milestones has different answers depending on where you got your bits from.  I’ve personally resorted to hosting a page on our team wiki with the title Tim’s Guide to Finding a Build Combination™.  I’ve also added a few helpful scripts to get any missing pieces aligned for builds.  So now I’ve got my daily build routine down to a science.

Occasionally there are times where a fix is completed and I look back at my tracking bugs.  Sometimes you’ll get a team that just fixes things and you aren’t given a chance to test out private bits, or whatever…so you have to go hunt down where the fix is at and when it will come to you.  In most source control systems there is a good mechanism for viewing/following a changeset.  In TFS I think they’ve nailed the feature to do this in two ways of visualization.  You can “track changeset” and choose a timeline view or branch view…it is awesome for pinpointing just where a fix is working the way through the source depots.  Here is a view of a bug using the branching view.  Green shows which branches has the fix (changeset):

Here is another bug using the timeline view showing me when the fix made it to certain branches:

For me, this has been invaluable to really identify when/where things are and determine a predictable path for resolution on issues as they converge.

Managing a process to get a Good Daily Build™ is not always easy when you need pieces coming from two different organizations which are very large and working in many, many branched source depots.  But staying on top of things so you can quickly help your customers/partners move forward progress is a very rewarding experience.  My daily routine has helped me stay on top of the core issues at hand and determine a daily quality on the mainstream scenarios as our customers see them, which isn’t always caught with test automation or unit tests all the time (but yes, we have those too).

Well, a new build just came out…time to update my wiki!

Today there was an event in San Francisco which introduced the Windows Store for Windows apps as well as some details on revenue sharing and policies.  As a part of that Antoine LeBland, Vice President for Windows Web Services, also opened up a new dialog about the store specifically in a new blog Windows Store for developers.  This blog will help developers learn about aspects of the store as well as serve as a place for dialog between the store teams and you, the app developer.  I think it is great that the store team is following in the footsteps of the Building Windows 8 blog and reaching out to share some of the high-level and, hopefully, behind-the-scenes aspect that makes up the store.  I look forward to future posts on the blog.

The inaugural post reviews the events that transpired today sharing some information for those who were not there, as well a a video clip of some of the highlights from Antoine and Ted:

The key store highlights discussed in the post are:

• Designed for discovery – store will be searchable and permalink-able (is that a word?)
• Flexible business models – including in-app trial upgrades, etc. as well as flexible payment options
• Transparent terms – clear understanding of the terms as a developer/business
• Best economics – you’ll have to read the post about the revenue split and advantages after certain milestones

In addition to this news, Microsoft announced a First Apps Contest.  The basics of this contest are that you have the opportunity to show your awesomeness to the world first.  The contest will select eight (8) winning apps to be the very first app in the Windows Store when it opens.  You’ll also get some goodies as a winner such as a Samsung Windows Developer PC and 2-years worth of subscription to the store as a developer.

The contest starts now, so be sure to read the rules and register and learn about what is required of you.  This is a great opportunity to be a first-mover in the Windows Store which will have some incredible reach opportunities for you as a developer.

I can’t wait to see the types and compelling experiences that developers will create with our platform…get started!

Well, today I received my Kindle Fire.  I pre-ordered this on Sep 28 when they were announced.  I’ve been eagerly awaiting to see if there is anything that can be a better-priced tablet-like consumption device like iPad.  I absolutely love my existing Kindle reading device.  Love it.  If you are looking for an e-reader device only, you should look no further than the Kindle reading-specific devices.  They are priced so good now that there is no excuse if you are an avid reader and have always wanted one.

Before I get to my “review” I wanted to share a little bit about myself, my usage and my reality with these types of things.  I hesitate to even call this a review because I’m not a gadget reviewer, paid jaded journalist or a fanboy of any kind when it comes to these things.  My allegiance is to awesome products that are practical for me.

I currently own an iPhone 4, iPad 2, MacBook, Lenovo, Roku, XBOXen and a Windows Phone.  In the past I’ve also had an Google Nexus One device but no longer have that (or other Android device) in my possession…until now.  I use my devices for personal use mostly, but as a super nerd…it is hard to say that I don’t use my phone as my communication device for work either.  My usage is mostly consumption.  I look at my calendar/contacts, watch movies, listen to music, read books, take pictures, play some casual games, watch television shows and other Internet TV and read/compose email content.  I am not creating large content, movie trailers, etc. with any of my devices.  I like when things work, are easy to use (or easy to figure out how to work around things when they aren’t easy to actually use) and are responsive to my needs.  I don’t care/know about any clock-speed benchmarks on performance stuff between any devices that I’ve ever owned/used because, frankly, it doesn’t matter.  What matters to me in performance is my perception and expectations…now what a high-speed camera says. 

With all that said, here are my initial impressions after a few hours (not an exhaustive use, agreed) with the device from opening to writing this.  Forgive the thoughts if they seem random…they are in order of my thoughts and usage.  Also forgive some of the Apple comparisons…but I trust you’ll understand them to be valid as they are the king of user experience.

Packaging

I friggin’ love Amazon packaging.  It is industrial but easy to use, no tools required, and just ‘get to the product’ fast.  I’ve often said I’d love to sit in a focus group and watch all the executives from cereal companies open their product boxes.  The Kindle Fire packaging is just what you’d expect from amazon and with a pull of the cardboard ‘zipper’ I was at my Fire.

I pulled it out and my gut reaction was huh, this feels heavier than I’d expect for the size.  The size also struck me as small initially…even knowing what the dimensions were.  It is just a bit smaller than my Moleskine that I use…which, in fact, is kind of an advantage as I can carry the two together (surely someone will latch onto this and make an awesome case). 

 

The one thing that disappointed me was the power cord.  The current Kindle’s that I own have a well-designed power cord.  It has personality, compact and just has that just here to give you power kind of attitude.  The Kindle Fire one feels like I just bought a ThinkPad laptop.  Disappointing.  But I realize this is a power cord…still, just feels like a step back in product design when compared to their existing platform.

First power-on experience

Sorry Amazon, you colossally failed here.  Now I’m not complaining about the speed because my iOS devices take forever from a cold boot.  But I could sense the Android-ness of the boot here.  The logo flashed a few times rather than a consistent image on screen.  This just made it feel unpolished a bit.

But that’s not the part that bothered me.  Immediately upon getting to the first screen, I was greeted with a list of wireless networks.  Very nice start.  I selected the one for my house which is WPA-2 protected and I have a long passphrase.  I was prompted quickly to enter the phrase and presented with a keyboard in portrait orientation (more on orientation in a minute).  The keyboard really felt comfortable in the portrait orientation and I could use it quickly. 

Once I entered my password and clicked next, it immediately recognized me…as the Kindle owner.  And by this I mean it said “Welcome TIm Heuer” and connected to my Amazon account.  I suspect they associated my serial number with my account pre-ship and this was a good touch.  I had the immediate impression that my library of content would be immediately available (more on that in a bit too).  However, this is where it went downhill…fast.

The screen then said it was downloading updates.  W.T.F.?! 

My first impression of a brand new device that hadn’t been on the market was that an update was already needed?  Big time un-polish.  I was not even able to get to any user screen and this update is in my face.  I figured it wouldn’t take that long though…after all, what could need updating already.

I was wrong.

I didn’t clock-time it but I was able to complete the following before the 100% mark was hit: eat a bowl of cereal (already poured), wash my bowl, vacuum my kitchen wood floor with a quick sweeper, go upstairs to take off my shoes and put some slippers on (yes, I wear slippers when I get home…don’t be jealous), come back downstairs, get a drink, get a pad of paper to start taking some notes, and then sit down in the living room.  There are a lot of factors here that could be in play like WiFi strength, bandwidth, etc. but the bottom-line for me was that this was a horrible first impression.

All that aside I figured it was done.  After all, I hadn’t even got to a real user screen yet.  Nope, it rebooted.  Ok, fine let it reboot.  After the reboot I was then presented with an Installing Updates screen.  Seriously?  Man, this was frustrating.

It applied the updates and brought me to the start screen.

Start screen organization

FIrst a note on the lock screen.  This appears to be a portrait-only orientation thing.  This seems odd, but not a deal-breaker by any means…just odd.

After a quick little walk-through on-screen of where things were, I got presented with the start screen.  There wasn’t a ton there but the Facebook logo was prominent as was some simple navigation that was obvious: Music, Video, Docs, Books, Apps, Web. 

Your 'recently used’ items are presented in sort of a bookshelf flip view thing.  Then there is another ‘shelf’ of where you can put favorites.  Fine.

The device doesn’t seem to respond fluidly to orientation changes and the change is abrupt feeling.  There were times I did the shake it a bit because that is supposed to wake up the gyro move to get it to flip.  This is slightly annoying.

The presentation of items in the shelf-flipper-thingy is pretty responsive to navigation in touch, although I felt the number of items it scrolled on a small touch gesture was too much.

Navigation

I didn’t think I’d mind not having any hardware buttons, but I do.  The lack of a ‘home’ button is kind of annoying especially since the device itself is hard to distinguish the top of it.  Having a hardware home button I think is key.  It is the eject button to get you back home no matter where you are in the device.  Kindle Fire doesn’t have one.

Instead they maintain navigation through a toolbar on the bottom, which does have a home button.  When in apps it can be visible or will be subtly hidden and you have to tap it to bring it up.  It isn’t always obvious, but it is there.  Still a hardware home would be nice.

There are also no volume hardware buttons.  This bothers me less actually.  Most of the time when needing to change volume I’ll be in an app that has these controls or me.  It’s one of those nice-to-have features but I don’t think it degrades the experience too much.

The picture presented here in this section shows you my touch points on the screen used after a few hours…this should give you an idea of all the places I had to touch to navigate in different areas.

Mail, calendar, contacts

I quickly went to configure mail.  Colossal fail #2 for the Kindle Fire.

I was presented with a screen asking what type of account I had.  Sweet, I picked Gmail.  I was then asked my login information, which I provided.  Then I was presented with What kind of account is this? screen and asked to choose POP or IMAP.

W.T.F.?!

I am currently awaiting a phone call from my relatives who bought one of these to have me help walk them through this phase.

This is horrible.  POP/IMAP is not user-friendly things to put in front of users unless you absolutely have to.  I’m not convinced for the major email providers they present as options this is at all necessary.  The problem is clearly that I use Google Apps for my domain and Fire doesn’t understand that.  This is a shame.  I was unable to complete my email setup without looking up settings.  Fail.  Fail.

I then also noticed explicitly on the mail screen that it calls out that you will not be able to connect to a Microsoft Exchange account without buying an app separate for this.  Fail #3 in the mail experience.  Seriously, I realize that they may not cater to Exchange, but iOS supports this as well in their platform!  My suspicion here is licensing…but that is just a guess that Amazon just didn’t want to do work here and rely on the Android app ecosystem…which will fail them.

So in the end I did not set up mail…it is just too cumbersome and is not going to fit my needs.  This is a minor problem as I can use web mail, but still annoying.

There doesn’t appear to be a calendar app at all.  Not just to sync with my actual calendar (which won’t work anyways since I use Exchange), but not a calendar to even look at.  This seems odd.

Contacts is there, but again, no sync. 

Basically this will not be a mail, calendar, contacts device for me.  This is a problem for my usage.

Media content

I do use Amazon media content and am a Prime member.  I have a set of music in Amazon Cloud player and also regularly rent/view movies from Amazon.  The video and music experiences are acceptable to me here for the Amazon-based content.  I have no real complaints.

As I noted earlier when I turned on my device it automatically recognized me as the user.  These media areas are tightly integrated with your account so I didn’t have to “log in” anymore to use them.

There is a Pandora app that came pre-installed and I configured it with my account.  The interesting thing is that when I launched it I was warned about data usage fees.  I realize this is because this is an Android app that is used elsewhere, but it shows the lack of customization tailored to the device.  This is a WiFI only device right now…I shouldn’t have seen that warning.

Hulu and Netflix were my next tries.  I had to go to the Store to download these apps first.  These both installed fine and I was able to configure my accounts quickly.  I actually like the Hulu app.  I think it feels right from a UX perspective and the playback was fine.

Netflix app needs some work.  Frankly it feels like they are wrapping their web site.  It sucks.  It most closely resembles their Roku app, which sucks just as equally.  Part of me suspects it actually is the same app.  The input controls, etc. just didn’t feel like they belong.  Regardless I was able to watch movies.  That’s what counts I guess.

Store

If you’ve never used Android before, then the store will appear unfamiliar in some ways.  I’ve seen this before and was able to quickly navigate, understand how purchases are queued in the background, etc.  I had no real problems here.

What I find interesting is the lack of consistency that Amazon is enforcing in the Fire.  The Facebook, Pandora, Hulu and Netflix app icons are all different sizes.  The Netflix one is clearly their iOS one…as does the Pandora one feels the same.  When these are all next to each other on the home screens in the ‘shelves’ they really do look inconsistent (size, rounded, square, etc.) and some are just blurry.  No attention to detail here.

The other thing I didn’t like about the store was the amount of email receipts in my inbox!  Amazon hasn’t figured out how to batch things.  This is only slightly annoying but after getting used to the fact I can make 10 purchases over the course of 2-3 days on iOS and get a unified one-receipt mail, this is another lack of attention to detail.  Not a show-stopper, just an observation.

Reading experience

This is a Kindle after all, right?!  I’m not an avid reader, but have been reading a lot lately.  My Kindle 3 works great for reading and is easy on the eyes.  I don’t think you can really beat e-ink.  The reading experience on the Fire is much like the iPad.  It’s a glossy screen, very bright, and for long reading intervals probably won’t be great.  I have changed my colors and font sizes to adapt to this.

Other than that the reading experience is fine.  Touch to page flip, etc.  No complaints here.

Be sure to protect your Kindle Fire with a case. Caseable allows you to create a custom case for your Kindle

“Other” category of feedback

Here are just some thoughts on some other areas of feedback

• touch performance seems inconsistent from app to app and even within the Kindle’s own apps
• Keyboard doesn’t auto-dismiss in areas where it should for me
• auto-complete/correct are annoying – this is not a Kindle-specific problem as I realize every system needs to be trained
• since the speakers are on the ‘top’ of the device, when lying on a desk to listen to music I prefer the landscape orientation and the music app actually looks better in that view, IMO
• web browsing seems fine. it doesn’t feel as fast as they keep talking about, but so far frankly no browser seems fast to me. I wait for pages to load and deal with it. The Fire browser isn’t fast to me, but doesn’t feel terribly slow either when compared to my real use on iOS Safari as well.
  • Note that YouTube defaults to their mobile site, which royally sucks (unless iOS)
• Web pages as apps – Facebook and Twitter actually give you icons as “apps” but really just launch the web browser to their mobile site views…nothing special as an app.  If you want a better Facebook/Twitter app experience I recommend the Seesmic app as it will do both in one app quite well
• The Amazon settings seem to be broken on my device
  • It gave me the option to name my device, which I did, but despite that the upper left corner of my device still reads “Tim’s 3rd kindle” which was the default name…and yes I’ve rebooted a few times.
  • The app has a “Your Account” tab on the top that no matter how much I stare at it or tap it, does nothing.  No idea.
• No opinion of battery life yet
• The lack of camera, microphone don’t bother me.  My iPad has these and the camera sucks and I don’t use it anyway.

Overall impression

The thing that frustrates me is that Amazon cut corners here.  They have one Kindle Fire device.  They aren’t saying that Kindle Fire is available on Android tablets…they made one.  Because of this I expected a really tailored experience…and am not seeing it.  You had one platform to optimize perfomance, you owned the implementation of certain things, etc…and you took advantage of little of that.  You put a good start screen on content…but didn’t tailor the other portions…this is a shame.

If you also want to be a serious contender there are also areas you shouldn’t rely on the app ecosystem to fix for you.  I am primarily talking about the ‘work’ side of things.  Seriously, invest in a good Microsoft Exchange story here.  Get the mail client to work with it, make it better than 3rd party apps and create a calendar app too.  Give me, the user, the integration that feels right.  Don’t make me install 2 apps to get mail/calendar and then I have 3 separate apps that don’t integrate with each other *at all* – not good for the user.

For the price point, this feels like a good device for those who want to consume media and books but don’t want to shell out for an iPad.  After using it I am liking the size a bit more.  I think all the arguments of the amount of apps available for the Kindle Fire is a bunch of BS.  It isn’t about the number of apps…it is about the amount of apps that matter.  They big name casual games are there, the big media apps are there, etc.  So far there is only a few niche things that I “miss” but can still live without. 

Will I keep this device?  Not sure yet.  The mail/calendar/contacts thing bothers the heck out of me.  I’ll use it for a few weeks on my normal consumption to determine the realism of if I’ll use it.  I think I will, but need some more real-world usage on may day-to-day life to determine.

If you only want an e-reader, don’t get this.  Get the $79 Kindle or Kindle Touch.  This will be over-kill, confusing and not great on the eyes for *lots* of reading (neither is the iPad).  If you use Amazon services already and want an Amazon-driven experience for that content (books, Amazon MP3/Cloud Player, Amazon Prime, Amazon Instant Video) then this device seems reasonable to acquire for the price.

Hope this helps!

I was searching my archives for sending something to my team this morning after looking at various bugs logged from customers, internal partner teams and ourselves.  I had an old post from 2005 but it unfortunately used a Shrinkster URL that appears not to be working.  So here’s the mail I sent to my team this morning.  This is purely my opinion but things that I think make a great bug report for fastest resolution:

------

As we triage and such I know that there are likely times that you are frustrated with not enough detail to even determine if this is a bug or needs investigation. This leads to feature teams spending time doing unnecessary things getting more data…and the cycle of time eventually delays product quality. To that end, when *we* log bugs I’d ask that you take into account my opinion of the “anatomy of a good bug”:

• Title: Required. This is obvious. The title should be concise but describe the problem in one line so that someone can quickly glance at it and get a feel of the issue immediately. Something like “control doesn’t work” is not helpful. Something like “TreeView shows blank nodes when binding to hierarchical data” is much more descriptive, yet concise.
• Path: Required. Almost every bug system requires and area/path assignment. You should do your best to assign this to where you think appropriate. If you are crystal clear, select the specific path. If you aren’t, then don’t guess too deep. Putting something at Product\Feature-Team\Feature-Area\Functional-Area\Control-Name might be too “deep” of a guess and would get bounced around. When in doubt, get up to the feature level and let triage teams who likely know the right path put it deeper or re-assign.
• Keywords: Optional. This is helpful for you usually. If there is a place to set keywords, you should consider putting some that might be helpful for searchers or yourself. However don’t spackle keywords all over titles/descriptions.
• Assigned: This usually defaults in bug systems to something like “Active” or “Not Assigned” – unless you know the specific person it should be assigned to, don’t guess.
• Priority/Severity: Optional. This usually defaults in systems as well. If you think the default is not correct for your issue, then change it. But if you are changing it to a higher (read: must fix ASAP) then you owe it to someone to send an email out. Logging high-pri bugs without an email is usually not a good idea.
• Build/Branch/Version: Required. Systems call these things different, and sometimes they are individually separated as well. However, this should be seen as required information. When someone looks at a bug they should know on what version of software you are using. They may immediately know “oh that was version 4.12, cool I know we fixed that in 4.2” and add that information to you back. Absent that information the investigator is left guessing on which build/version you were using and they may be flailing for a while with various versions. Even if there are fields for this in the system I usually always put this at the top of the repro steps as well for greater visibility.
• Description: Required. Yes you put a title, but you still owe it to the investigator/triage to provide a bit more depth. The description should re-iterate the title, but also provide the scenario and other supporting detail. Things like “it worked in version XYZ” or “works on competitor platform Z and adds significant value to customer” are some additional data points that help understanding why you are logging it. Descriptions maintain history of the bug so pasting emails for context, etc. are entirely appropriate IMO.
  • NOTE: I used an example of “worked on version XYZ” – some systems have specific indicators whether this is a Regression or not. Even if they do I would indicate regression data in the description.
• Repro Steps: Required. Perhaps the absolute most critical portion of your bug log. IMO this should include:
  • Version/Build/Branch
  • Steps – verbatim – yes I usually write these out with numbered lists:
    • 1. Open VS
    • 2. Create new C# Application
    • 3. Open designer and write this code
    • …
  • Once you hit the issue at hand break into Expected/Actual statements. This is where you would note what you Expected (i.e., “Control would render on UI surface”) and what was the Actual (i.e., “UnhandledException of type foo shown and crashed VS”).  In the Actual section would be a good place to paste call stacks, exception messages, etc. in addition to any simple error seen.

Here’s a template I use for the “repro steps” area of a bug report to remind me:

Repro on Version XYZ

Repro Steps:

1. Step 1
2. Step 2

Expected:

What did you expect to happen

Actual:

What actually happened

I find this has been helpful to continue to remind me of what is required and helpful.  Most systems allow you to create bug templates.  I have a bug template that includes this primer data in the repro steps for me.

• Sample Repro: Required. In my opinion, this is required. There is no greater path to resolution or understanding of a given bug then by having your specific issue immediately available. Without it the repro steps are helpful but may not be detailed enough in the code that you are using as well. This sample repro should be isolated to the issue at hand and should be simple to get up and running. If you send me a zip of your ERP system and expect me to fix why text is right-aligned incorrectly, that’s a colossal waste of my time getting a huge app set up trying to find the one issue. Often this exercise of narrowing the repro also identifies some issues where it might be user code. Regardless, provide a repro and keep it simple.
  • Sometimes attaching screenshots of what you are seeing is appropriate as well to help with an issue that might be a visual one and leads to faster understanding than setting up the repro.
• Close Bugs: When bugs are resolved back to you as fixed do your diligence to verify your bug quickly and close it out. Historically up to 15% of resolved bugs are re-activated. If we re-activate too late, we run the risk of missing key quality points in that area where you logged the bug. If you cannot verify it (because of time, out on vacation, etc.) then reach out to a test lead and indicate you cannot verify soon enough and request assistance to re-assign the Resolved bug to close.

Following these principles helps drive quality into our products. It does this by leading to faster times to get to understood, agreed-upon bugs. Please make sure we help our own team and partner teams when we log bugs to ensure we’re providing good information to help them fix what we think are issues.

------

I hope this helps perhaps as some guiding principles when you log bugs against products that you use and/or within your own team.