Blender 2.8 is going Beta. What now?

Question

Blender 2.8 is getting its Beta status today or tomorrow. Which means that we can expect the interface, workflows etc to be in their final form. Bug fixes, and bringing back of features that were lost during the refactoring will still happen.

I think this version change is big enough to require some consensus about what to do with old and new questions on the site.

I think some things will happen spontaneously and are not going to be controversial:

• people answering questions about (unchanged) workflow will probably use Blender 2.80 screenshot in their answers with no harm to their back-compatibility

• new answers using shortcuts or commands that have changed will probably include a "please note" to remove ambiguities

Some other things are more dubious, especially the ones regarding old questions.

1. Should we edit old answers to update the shortcuts, menu placements, etc, mentioned within them? (e.g. did you know we went left click select this week?)

   If yes: how should we do that? By starting a campaign that will bump a lot of old questions to the homepage, or by just updating them if we stumble upon them? Should we limit ourselves to 1k+views questions?

2. If a question has a good, accepted answer that relies on a < 2.79 workflow (e.g. uses layers extensively), or an answer that correctly (for that time) says "Thing X is not possible", should we:

   1. answer the question with a new 2.8-inspired answer and hope that it will get noticed? (but by doing so, we are "stealing" 15 rep from who gave the correct 2.79 answer)
   2. allow duplicate questions, as long as they have tried the 2.79 answer, which didn't work, and are now seeking a post-2.8 answer?
   3. ask duplicate questions ourselves (meaning: established users, without waiting for a "genuine" question) and answer them?

Answer 1

I'm against editing the answers at all because there are people who will keep on using 2.79 for various reasons: they have an efficient workflow and switching to 2.8 would be very disruptive to their work, add-ons or third party program that they use with 2.79 will not work with 2.8, their computer cannot handle 2.8, they do not like the new interface, etc...

Having answers for both versions allows us to be a resource for everyone, so we should either allow semi-duplicate questions for 2.8 or post a new answer to an existing question and label it clearly as a 2.8 answer. And we could just edit the previously accepted answer to add something along the lines of 'This answer works for 2.79' or something like that.

Answer 2

My vote is for handling each on a case-by-case basis, but roughly following something like this:

• If a question has a duplicate for < 2.79 which differs significantly from the would-be 2.8 answer, answer it like a new question ("How to do X in 2.8?).

  If the < 2.79 question is very highly upvoted/appears high in search results, then add a 2.8 answer on it with a link to the 2.8 question (with sufficient information to stand as an answer on its own; perhaps highlighting the differences between the 2.8 and < 2.79 ways).

• If a question has a duplicate for < 2.79 which differs very minimally from the would-be 2.8 answer, either edit an existing answer or post a new answer on the < 2.79 question and close the 2.8 question as a duplicate.

  Whether to create a new answer or update an existing one depends on exactly how identical the 2.8 and < 2.79 ways are. If "2.8ifying" a < 2.79 answer makes it unfollowable for 2.79, that's probably a good indicator that a new answer is in order.

Naturally the degree to which the < 2.79 ways and 2.8 ways differ is subjective, and in fact there may be multiple answers to one question which each differ to differing degrees. I'd err on the side of the first way (i.e. answer it as a new question).

Answer 3

I don't think editing old answers is a good idea. For the same reasons as @Sava exposed.

But we can think about how we should behave in the next months.

First, we are not sure LCS will remain default (still Beta version). And if it does, it might change through time as it is already being.

Second (and I think it's the most important), if there is one thing that LCS makes clear for sure: we don't know how tomorrow will be for Blender. Maybe in ten years, there won't be RCS anymore, or Industry Standard keymap would have take over the world, or we would have reverted RCS default, or we would have a completely new paradigm like that one making today's concerns completely wiped out.

And it's not even to mention the user's customization.

So, considering that, how do we provide answers being as efficient as possible and through time?

I think that we need to educate ourselves in how we deliver information.

As said William Reynish here:

This is a general thing for tutorials: In Blender you can customize the keymap completely, customize the theme, the layout - everything. If you make tutorials I would suggest two things:

1. Use default settings as much as possible
2. Try to not refer to features by their hotkey only. Do not call it ‘N-key panel’ or ‘W-menu’, but refer to features by their name, and secondarily (optionally) mention the default hotkey if there is one.

We might finally use Blender's UI vocabulary. Blender has already a precise UI vocabulary, giving us a solid base to precisely indicate any UI part of Blender without being dependent of a language barrier, keymaps, customized themes or UI arrangements, ... On top of that, the UI isn't gonna change that much through years so we're good for a while (and if it does change, old answers wouldn't be any more valid anyway and we would just change with it).

On top of being quite understandable and being more precise through time, it will make the information reliable for more people.
Not to mention that, for a lot of people, a descriptive indication is identified and learned quicker than a bunch of shortcuts or tons of different names for the same thing.

But, for the transition time, I think we will need to actually be polyvalent in our answers. Maybe take the habit for a while to give both keymaps shortcuts. But always start with functions and UI names, the official ones as long as possible.

Answer 4

This stack has more than enough duplicates already, and often it can be hard to find useful information in the sea of dupes. For this reason I much prefer options that stay under the original question, rather than add to this.

My preference would be to edit when its a single line correction e.g:

Note: from 2.8 onwards the shortcut for X is now Y

And a new answer for where the workflow has changed more radically, possibly editing the old answer to indicate it applies to versions prior to 2.8.

Under no circumstances should we be making duplicates, as I feel this will just make stuff harder to find. People generally don't indicate a version when they are searching for answers.