Should we change the question on the Tour page?

Question

The Tour is a page shown to new users, intended as a quick introduction to the site. As part of this, there's an example question shown to the user:

The current question, Triangle Area Side Side Side, is both closed and inconsistent with the expectations for a new challenge. It has a brief description, badly formatted test cases (and only two of them), and no details on things like allowed input/output methods.

Should we choose a new question? Answers here should either be "no", or a proposal for a specific question to replace it with.

Answer 1

Yes, to Fibonacci function or sequence

• The challenge is short, so will fit into the cropped view from the tour page, but is still a well specified and clear challenge
• It's been consistently active for over 10 years. Looking at the timeline, there's been an answer posted at least once a month, every month since posting. This means we'll be demonstrating to new users that old posts are by no means forgotten, and that answering old posts is encouraged
• The top answers by votes, and therefore the two shown in the Tour, are Perl and brainfuck, which I think are great examples of what we do here. The Perl program shows to new users the extent to which we can twist "practical" languages to be incredibly short; the brainfuck program demonstrates a famous esoteric language to those who are less likely to be familiar with them
• It has an accepted answer. Even if we discourage accepting answers, it's still a core functionality of the SE platform, and should be demonstrated in the Tour page
• The "test cases" are prominently featured, close to the top of the question, so won't be cropped out in the Tour
• It's a very famous beginner programming task, up there with Fizz Buzz and Hello, World!, so a lot of people are likely to see it and think "Oh, I know how to do that", encouraging them to participate

Answer 2

Yes, to The vanilla factorial challenge

When I was writing this challenge, I tried to make many of the implicit rules explicit, such as default I/O methods, standard loopholes, built-ins, time/memory limits, and "theoretically being correct is valid". I think this list serves as a brief guideline for new plain code golf challenges. If others think it matters, I can add links to the relevant meta posts for each of them.