Follow-Up 3: New Site Name and Help Center Discussions

Question

Chat Transcript: New Site Name discussion Sep 9, 2016

Previous Discussion: Follow-Up 2: New Site Name and Scope Proposals

---

Ana stopped by (Shog was not available today), and maple_shaft was around. Here's a summary of what we talked about:

Ana looked at the only up-voted proposal last week that didn't include the term "SDLC". Although it was a good proposal, the use of the term "SDLC" was the thing that got everyone involved in this discussion onto the same page in terms of what this community truly represents in terms of who we are and what we offer. We'll be sticking with the taglines that we came up with last time going forward.

We then took a good, hard look at the bullets that describe what is on-topic. It seems 4 is the go-to number, and we managed to get it down to four:

• development methods and practices

• requirements, architecture, and design

• quality assurance and testing

• configuration, build and release management

The word "software" was dropped. On a site named Software Engineering, it should be pretty clear that questions should be about software development. It just added a little extra verbosity that should be apparent to users who are reading the page - it will be in the URL and the logo.

We brought in the "development methods and practices" to better advertise that these topics are on-topic. The first tag that falls into this category is agile, which is our 22nd most popular tag. Since there isn't a whole lot of visibility into this category of questions when you hit up the homepage or at the top of the list of tags, we felt that it was important to include.

We also combined "requirements" into "architecture and design" to form "requirements, architecture, and design". These are closely related topics. There are many architectural and design questions, but it's important to recognize and advertise other topics, like requirements, requirements-management, user-story, use-case, and so on.

The biggest change is that we eliminated the line item for "algorithms and data structures". But this doesn't mean that these questions are off-topic, because they aren't. I had a little back-and-forth discussion with maple_shaft, and since the SE folks really wanted 4 items, we felt that the type of questions that we want here are sufficiently captured under the "design" portion that we call out in the Help Center, but also the existing questions that can be used as a good example.

---

Please leave any further comments in here. They will be reviewed and discussed when Ana (and maybe Shog) come back next week.

Answer 1

When I read this post, my initial thought was, "If I upvote this, will it be interpreted as either (a) 'I approve this on-topic list' or (b) 'I approve further discussions of details'." And honestly, I don't like any further discussions until the main point (changing the name) is implemented.

You see, "If we're gonna do this... Let's do it right." argument would apply if we were going to engrave this list into a titan plate to send it in the depths of outer space, right to the dark stars, where Elder Gods would read them and decide whether we get to live or not. I wonder if Cthulhu would approve including "algorithms and data structures". I bet he doesn't like any kind of structures.

But we are talking about a text which can be edited within 1 minute, right?

So, can you just ship the changed name first, without wasting weeks on discussing details? We can always spend more time later, once the main problem is fixed, which is the constant flow of new users posting off-topic question because they are being misguided by the name. (They haven't checked the help center anyway, obviously.)

---

I approve of any list. The current one is good, the new one is great. Four bullets or five, it's fine.

plox <(_ _)>

Answer 2

Just one thing here:

• development methods and practices

• requirements, architecture, and design

• quality assurance and testing

• configuration, build and release management

Isn't testing a development method and some kind of practice?

My overly brief summaries of the points would be along the lines of:

• what to do and how to do it
• from client to code
• how to make sure stuff is good
• from code to client

Where point 2 appears to be distinctly about "whiteboard" concepts and point 4 about the management of the overall toolchain, points 1 and 3 appear to be both about the "programming" of things. quality assurance and testing seems to be just a specialised case or subset of development methods and practices.

Is this because the whole aspect of "how to make sure stuff is good" is so important that it should be pointed out in its own bullet point? What if point 1 and 3 are merged, for example:

• development practices, quality assurance and testing

• requirements, architecture, and design

• configuration, build and release management

Now the category of each bullet point appears to be much more clearly distinct from the other ones.

Would that be better? I have to admit I did not follow the discussion, but if you originally wanted to have more bullet points, this might free one up if you want to cover something else.

Answer 3

What's taking so long? Why is this process stalled? Let's do some software engineering here:

• Hypothesis 1: The development tools, methods, and processes are ill-fitting. I'm not into SE's back-end community tools so I may be missing key parts, but I see occasional promoted "New Site Name" questions and mentions of someone stopping by somewhere. This is not an effective way to form a team, clarify the problem, collect design ideas and ways to test if they work, do the tests, run it by the community, and decide.
  How many community members have contributed ideas or feedback on the proposal, or even seen the proposed SDLC tagline (that brings to mind Waterfall-model big project failures)?
  People are now so frustrated with the stall that they just want to launch a name change and hope it works (Waterfall style) and maybe measure the impact later.
• Hypothesis 2: There's no evidence that the proposal will help, some risk that it will hurt, and it entails a large rebranding impact on the community that can't be done often without losing people. There's no need for a long discussion. Opinions are not evidence. A little evidence goes a long way and testing can be quick and cheap. [Suggestion below.]
  The last time I did a usability test for an open-source project, we developers had brainstormed icons for a heavily used part of a web site so people could drag a web link icon to their home screen for fast access. I did the test in one afternoon, showing the designs to ~8 people. The results were stark: None of the designs got the idea across and nobody thought of that part of the web site as a separate thing. [If y'all ever get into a UI design debate, a usability test does wonders.]
  The Stack Exchange folks ought to have usability testers and ways to gather test subjects. If not, then we're really pushing uphill here. If they do, then it's surprising that each site's "what's in scope" bullet items are buried behind many steps and an animation.
• Hypothesis 3: The responsibilities are unclear. @ThomasOwens and others are pushing but action requires SE. Are @Ana and @Shog9 from SE? What does SE need to move forwards? Confidence in a proposed solution? I can see why it's important to do a single rebranding with site name, tagline, and in-scope bullets since you can't get broad attention often, but is it really necessary to continue tuning the bullets before launching the new name? Do you have evidence that 4 bullets is the most that people will read? Does that change if you put the bullets at the top of the page rather than within an animation halfway down the page?
• Hypothesis 4: Maybe nobody has yet come up with an adequate proposal. Maybe there isn't one within the constraints, that is, without fixing SE design problems like how hidden the site description is. Maybe off-topic questions can be avoided only by coordinated moderator action. Maybe people asking questions look instead at high-voted questions to judge if this is a good place to ask their question. That would require a different solution like, say, reviewing high-voted questions, attaching fitting tags from the proposed 4 bullet points, etc.

Suggestion: State the goal (requirements, such as "50% fewer programming-in-the-small off-topic questions") and test which proposals accomplish the goal.

Measure rather than debate guesses (hypotheses).

A usability test needn't be difficult, expensive, or slow. E.g.:

• find a wide variety of people who've asked fitting and non-fitting questions on this site,
• show them the proposed site name, tagline, and 4-bullet description,
• ask them which of various sample questions seem in scope vs. out of scope.

The name "Software Engineering" fits for me but maybe the people asking SO-like questions consider it just a synonym for "building software" (as @ricksmt noted).

The proposed bullets make sense although they don't mention the deeper points of using principles to engineer a success and evaluating success (qualities like safety and reliability).

It helps to test more than one proposal. There's a "draft 3" alternative at the end of a previous answer.