Follow-Up: New Site Name and Scope Proposals

Question

I've been pondering these proposed changes to the site's name and scope for the past few weeks. This was, you'll recall, instigated by Ana's response to Rachel's proposal for a new name for this site..

Why are we changing anything again?

The purpose of that name-change request was explicitly to end the confusion over what this site is about. Ana's request was that y'all do a thorough review of your scope at the same time, for exactly the same reason. Because, let's face it: when you gotta have a chatbot running to catch all the folks who erroneously recommend your site, there's some pretty widespread misunderstandings as to what your site is about... To put a stop to that, we need a clear, succinct definition:

Above all else, the scope needs to be simple. Seriously. No more than four bullets, no multi-line comma-separated lists, no gerrymandering - it needs to be easy for any new visitor who bothers to read and even mildly pays attention to what they're reading to know what they can and cannot ask about here. Eliminate ambiguity for a first time poster once and for all.

...because, remember, that was the whole point of doing anything at all. If we can't do it right, there's no point in doing it.

The proposed changes are not exactly succinct. They're... the sort of laundry-lists that make folks who already know what the site is about feel good, but don't do anything to help or hinder the folks coming here confused. You want to establish a path of least resistance that isn't asking a sketchy question and seeing if it sticks - if I make it past the home page, through the signup process, past the tour, and get to the Ask page, I'm probably going to ask a question regardless of what text you throw at me... Folks tend to build up momentum as they make decisions; you don't want to wait until the last possible moment to tell 'em they're in the wrong place.

What I think you're asking for

That said, there's a lot of good stuff mixed into that proposal, if you take the time to dig a bit. After talking to folks in chat a couple of weeks ago (and then another two hours talking with Ana today while she patiently guided me through it), I came away with this as the structure of the proposal:

Name

Software Engineering

Description / tour tagline

question and answer site for people directly involved in the Software Development Lifecycle who care about writing, shipping, and maintaining code responsibly.

On-topic

• software architecture and design
• algorithms and data structures
• quality assurance and testing
• configuration, build and release management

Off-topic

• troubleshooting or debugging code
• requests for code
• what to read, learn, buy or use.
• legal advice

That's short. I could theoretically paste that entire quote into a comment, and still have room to reply to someone by name and properly cite its source.

More importantly, it's short enough that it might actually get read by the hundreds of folks who clearly aren't reading anything here today. Which was, again, the entire point.

Note that I dropped a few things. That's ok; you don't need to exhaustively document every possible topic that falls under the umbrella "Software Engineering" - the ultimate source of truth is what's actually on the site. If someone comes in from Google because there's a question about Agile they're interested in, it won't matter that it's not explicitly called out in the docs. On the other hand, eliminating requirements and methodologies from that list also lets you avoid having to qualify those topics with a paragraph about where to stick broad, opinionated discussion questions.

What this site is really about

I love the idea of a site about software engineering, especially one created as the evolution of this site: it fits the spirit of what y'all are doing, gives you a name and a topic you can communicate with pride, and even resolves an old, old dispute in a less depressing fashion.

But none of that matters. What's important here is whether y'all actually believe this reflects what you're doing. Remember, the goal was to clear up all those cringe-worthy misconceptions... Not to create a whole pile of new ones. So I ask of you,

1. Does anything in the quote above strike you as incorrect?
2. Does the quote above reflect the site you know and love?
3. Is the quote above something you'd feel comfortable giving to someone unfamiliar with the site, by way of an introduction?

Thank you for your time.

Answer 1

I Love It

In short, our scope does in fact have a few small edge cases that are well established but relatively uncommon (Eg. software license questions from the perspective of a software engineer, some overlap with Project Management) however is it terribly important that we complicate and confuse?

This is the problem when the community is a group of Experts and Engineers at the same time. The Engineer in us is over analyzing the living hell out of our scope statement and making it far more complicated than it needs to be. The Expert in us is building a tool that is designed as a reference guide for experts, at the expense of intuitiveness and usability for newcomers.

The scope statement is not primarily supposed to be a definitive reference guide so that we can drop hyperlinks on content from new users as proof that they screwed up. Let us put the human touch on content moderation and explain, coach and teach. Let us reference Meta discussions for long established standards and traditions where we need to.

Seriously guys... this site has been around for years now, do we really think that years of precedent and Meta discussion can be culminated in a single easily digestible page?

All in all, not a very welcome invitation any of the proposals thus far.

I think Ana kind of freaked people out saying that we had to get this perfect the first time because we wouldn't get a second chance. That is what set us into analysis paralysis and grid lock in the first place.

I propose we go with Shog9's succinct scope statement and just see how it goes. We can always make small adjustments at a later time. The only thing I can see we should get right first chance is the site name and I think we are all in agreement with at least that much.

Answer 2

I can (and do) certainly back this solution.

I particularly like the idea of getting the site scope over in as few words as possible so that we actually stand a chance of getting people to read them.

The fact that the scope is basically a definition of the new name also helps a great deal. The current name does cause the problem that visitors think it's about the people not the process. Explaining that it's not about the people is hard.

We have tweaked the current help pages quite considerably over the years, adding and removing explanations and bullet points etc. as we attempted to get it right so I don't see it as a problem at all that we go with what Shog proposes and gauge feedback later.

Answer 3

I think Robert and Thomas both make excellent points and we should heed their advice, but I would like to focus on something else.

On March 10, 2016, Rachel asked the question that set this whole thing off: (4 years later) Dear Stack Exchange: can we change our site name? On May 23, Ana answered the question. Two and a half months later, a CM finally responded.

The day after Ana answered the question, Thomas asked New Site Name and Scope Proposals (May 24). I think it was actually more like hours later, but I am going off of the date stamps on the posts.

We had four weeks to discuss this topic before a promised CM response, but it took until July 21. That is almost two months to receive any meaningful feedback from the CM team.

Actions speak louder than words. We have already discussed this topic to death. We already have community consensus.

I propose making the changes outlined in Thomas' answer (preferably with Robert's interstitial page) without additional months or years of bickering, arguing, and delays from the CM team.

The community at large already has a negative opinion of the tangible effects that the CM team provides: for reference, just take a stroll through Meta.SE at all the ignored and abandoned proposals. Or our own meta. We have some vocal users who just want some simple changes to increase quality. Be the CM that changes this perception and get this change moving.

---

N.B. as Durron mentions in the comments, this slow pace and the perception of poor communication has directly lead to the exodus of multiple active users who brought a lot of value to the site via community moderation and answering questions. This community needs change and quickly if it will stop the exodus and possibly even bring some users back.

Answer 4

Overall, I like it. The name is 100% spot-on. I think the scope statement is 90% there. I don't like dropping the two topics that are on-topic.

I think the most important thing is the site name (and, along with it, the domain name) as this is something that we need SE to do. The tour and help/on-topic page (with the tagline and description) can be refined by the community since they are mod editable, but what we have is pretty solid and very close to what we want. We are all in nearly full agreement for the site name, so I think it's time to get that ball rolling.

---

The proposed changes are not exactly succinct. They're... the sort of laundry-lists that make folks who already know what the site is about feel good, but don't do anything to help or hinder the folks coming here confused.

I don't know what you mean by this. The changes themselves are exhaustive: a new name, a new tag line, a much shorter /help/on-topic page that only lists the 6 core things that we are about, a request for an interstitial page that mirrors the proposed new /help/on-topic page, and a request for a new UI design that's more in line with sites like Computer Science and Electrical Engineering - cleaner, crisper, and more professional (in terms of the feelings invoked, not saying that the current design looks like it was done by amateurs).

If you really want a 4 bullet list of things on-topic, that's not going to happen. Depending on how you slice it, there are easily over a dozen subdisciplines (see Wikipedia or the IEEE Computer Society) to software engineering. If you removing the parts about coding, you still easily have 9 or 10. We got these down to 6 bullet points with links to Wikipedia pages (that at least some of us have read and agree are in line with our expectations). Between the name and 6 bullet points (as opposed to the 8 "about" and 10 "not about" now), it's much more succinct.

---

Regarding your proposed description/tagline and on-topic/off-topic, it's not right.

In the tagline, we aren't just for people directly involved in the SDLC. We're also for students studying the SDLC and researchers who study or write about the SDLC. We want to take a page from CS and EE and explicitly include these people.

If you want a third take on your proposed description/tagline, I'd say it's this:

question and answer site for people participating in, researching, and learning about the Software Development Lifecycle who care about writing, shipping, and maintaining software responsibly.

For the on-topic list, don't like how things were dropped. We aren't being comprehensive about what is on-topic. If we were being comprehensive, we would have over a dozen bullet points. We picked the most important things. I think that leaving out "methods and practices" and "requirements engineering" is doing ourselves a disservice.

If someone comes in from Google because there's a question about Agile they're interested in, it won't matter that it's not explicitly called out in the docs.

That's true. On the other hand, there are other sites where Agile questions get posted and accepted. There are still plenty of people who post methodology questions on Stack Overflow because of legacy questions there that aren't closed. These same topics are posted about on Project Management.

On the other hand, eliminating requirements and methodologies from that list also lets you avoid having to qualify those topics with a paragraph about where to stick broad, opinionated discussion questions.

You're just as likely to have these broad, opinionated discussion questions in architecture and design. And to some extent, build and release management. But that's not a reason to eliminate those.

In the end, I'd rather have "methods and practices" and "requirements engineering" back since it clearly defines our scope in 6 bullet points.

For the off-topic list, I think that's generally right. I think changing our name will make it clear that many of the things that we call out as off-topic now are actually off-topic. We may want to add "tool usage" (it's hit or miss - some sites allow tool questions, we decided we didn't want to) and "education and career advice"

I would like to be able to edit the /help/dont-ask page to include the off-topic things there, instead of making the /help/on-topic page too verbose.

---

Name

Software Engineering

Description / tour tagline

question and answer site for people participating in, researching, and learning about the Software Development Lifecycle who care about writing, shipping, and maintaining software responsibly.

On-topic

• methods and practices
• requirements
• architecture and design
• algorithms and data structures
• quality assurance and testing
• configuration, build and release management

Off-topic

• troubleshooting or debugging code
• how to use specific tools
• requests for code
• what to read, learn, buy or use
• legal advice

Plus, it still fits into a comment:

Software Engineering Stack Exchange is a question and answer site for people participating in, researching, or learning about the SDLC who care about writing, shipping, and maintaining software responsibly. Questions about methods and practices, requirements, architecture, design, algorithms and data structures, quality assurance, and configuration, build, and release management are on-topic. We don't accept questions about debugging code, using specific tools, things to read, learn, or use, education or career advice, or legal advice.

There are 59 characters left. I also added ".stackexchange.com/help/on-topic" to the box and still had 26 characters left. As long as we don't have a stupid long domain name, we can link to our site's help/on-topic page in any comment.

Answer 5

The goal of the participants on Programmers has always been the same: to have a high-quality Q&A. I think we all agree on what that means; we want to attract professionals to the site, help people with their software design questions, and promote a high level of discourse. I believe that the way to do that is to present a site to the public that embodies that level of discourse.

Those of us who are left on Programmers who still care about these things believe that the single most important thing that will achieve those goals is to get bad questions off the front page. Bad questions take time away from the participants that could otherwise be used to answer real questions, and they turn away the professionals who are the people we really want here.

The name change is something that we can apparently all agree on, and we should do that. I have concerns about the rest, especially if Stack Exchange is going to make the name change conditional on the other changes they have proposed.

Removing bad questions from the front page is onerous: it requires 5 close votes and 3 delete votes over several hours. That's too much time and too many people. If the question is clearly off-topic and cannot be salvaged, rapid removal should be the prevailing policy, and I'm open to better ways to make that happen.

However, the best bad question is the one that is never asked. Therefore, educating new users is paramount, and the way that I think you do that is to tell new users what they cannot do on the site. Which do you supposed is more frustrating for everyone: being told you can't ask your question here before or after you ask it?

There are three groups of people who visit Programmers:

1. Neophytes who want help fixing their broken code
2. People looking for general advice on a wide range of subjects having little to do with software engineering
3. People with legitimate questions who don't understand the site scope.

The only hope for groups 1 and 2 is to get a statement in front of those people about what kinds of questions they cannot ask, as closely as possible to the act of asking it. I believe that should happen either in an interstitial page with an "I agree" checkbox, or prominently on the Ask Question page. It doesn't have to be a huge wall of text; it can be as simple as this:

We don't do code troubleshooting here, so if your question is about how to fix your broken code or how to use your programming tools, ask it on Stack Overflow, making sure that you provide a minimal, complete, and verifiable example.

Please make sure that your question is directly related to the Systems Development Life Cycle. Avoid peripheral issues such as product recommendations, career or education advice, product support or legal matters.

For group 3, we believe that the site's scope description should be:

1. Clear,
2. Concise, and
3. Complete.

The Scope Description appears in the Tour Page and the Help Center's "What kinds of questions can I ask here" page. Stack Exchange wants us to limit our scope description to four bullets. Since a clear, concise and complete summary of the SDLC cannot be adequately described in four bullets, I suggest a single bullet:

• Questions directly related to the Systems Development Life Cycle.

It is my impression that SE is trying to make the bullets as simple as possible in order to not confuse new users. But if a new user can't figure out what we mean by "Questions directly related to the Systems Development Life Cycle," we probably don't want them on the site.