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 , 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 , , , , 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.

  • 4
    Thanks for posting this. If anybody disagrees with the decision on Algorithms and Data Structures then lets talk about it here. – maple_shaft Sep 9 '16 at 19:32
  • 1
    @maple_shaft Preferably in an answer and comments there so I don't get blasted with notifications on this question! :) Chat is also a good venue, but anything in chat should be linked to here so we (especially Ana and Shog) can find it easily). – Thomas Owens Sep 9 '16 at 19:33
  • 9
    If those guys really insists on only 4 bullet points for some formal reasons (for me it looks more these are superstitutious or bureaucratic reasons), then let it be, But for me this whole process takes - far - too - long, so we should finally end this discussion and let the actual renaming happen. We won't get it right 100%, but sometimes making a 98% decision at the end is better than making no decision and no decision, and still no decision at all. – Doc Brown Sep 9 '16 at 20:27
  • 9
    @DocBrown We examined the option of one or maybe two more bullets, but we managed to get it down to four without much trouble in today's conversation. Since that's what we were originally aiming for, we ran with it. A succinct /on-topic page was pushed for by CMs early on because in the time the Community Team has spent doing what we do, we've grown painfully aware that people become less likely to read when you put more (rather than less) text in front of them. We're trying to help. We're not being bureaucratic jerks for it's own sake. – Ana Sep 9 '16 at 21:52
  • 4
    Also, just a note on the "just get it done" philosophy, @doc: that's what we did 6 years ago. And it was good enough... Until it wasn't. So, now we pay down that debt. Taking on more debt to get that done faster is certainly appealing... But also rather pointless - we could just do nothing. So... If we're gonna do this... Let's do it right. – Shog9 Sep 9 '16 at 22:13
  • 2
    @Shog9: this is not about "just get it done quickly": My perception is though you already have completed the renaming task, you are still discussing minor, less important details to death. Whatever the site's description will be, there will be people who misunderstand that or ignore it - you won't be able to fix that. And for sure, no battle plan will hold the first combat - you will only know how good the description is until you put it live on the site. – Doc Brown Sep 10 '16 at 4:54
  • 2
    ... moreover, expect the renaming to be "good enough" for this time, again. Until (in a few years) it might be not good enough anymore again. That is reality, you can't prevent that happen. – Doc Brown Sep 10 '16 at 4:58
  • 4
    In my eyes, a much more efficient way would be this: instead of discussing details of the bullet point list over weeks, put the damn four point thing live, see how the feedback is and allow yourself to make minor corrections based on the results. – Doc Brown Sep 10 '16 at 5:03
  • 2
    Have to agree with @DocBrown. The more things you change at once the less you know about what caused what. – candied_orange Sep 11 '16 at 5:47
  • 3
    We asked if SE could change the site name and domain name first and then work out the details of the mod-editable changes later, but this is a one shot deal - everything needs to be done and in order and go live in one go. That means ironing out details like what the /tour, help/on-topic, and help/dont-ask will look like and a good definition of our scope that's understood by everyone here and the CM team. – Thomas Owens Sep 11 '16 at 13:07
  • 3
    SE as a commercial organization should have usability testers. Even a quick-and-dirty test is useful. Debating is slow and ineffective. Agility means quickly iterating and observing, not shipping to the world and hoping it works. – Jerry101 Sep 11 '16 at 15:04
  • 7
    I cannot believe the process to do something which the community overwhelmingly supports and is a straightforward change has taken this long. It is now over six months since this process started. Just pick something. Most of us care very little about the "defined scope bullet points" and instead care a lot about the site name. – enderland Sep 11 '16 at 15:05
  • 5
    I care about the bullet points. I feel like I'm being made to discuss them at the point of a gun. We changed scope such that the name change was appropriate long ago. The bullet points are just one of many things I take into account when I close. From what makes a good question to the community consensus you find on meta. We haven't been "programmers" for a long time. It's just time to change the sign on the door. Why that demands spring cleaning now rather than regularly escapes me. – candied_orange Sep 11 '16 at 15:53
  • 2
    The silver bullet is to stop looking for a silver bullet and get the job done. The name change won't fix human stupidity. It'll make us feel less like hypocrites when we explain we don't deal with every issue faced by "programmers". That might lead to fewer bitter arguments and maybe, just maybe, 1 question will benefit from that environment. If we're incredibly lucky it might be 2. – candied_orange Sep 14 '16 at 22:16
  • 2
    @shog9 Nobody reads those bullets. That is the reason I've pushed so hard for some text in an interstitial, in the tagline, in that banner band at the top of the page (New here? Read this!) or anywhere that cannot be so easily ignored. I really like the bullets you eventually came up with, but they're not the elephant in the room. That they're hidden from new users is. So we're not hanging our hat on the bullets; we're really, really hoping that the name change will be enough. – Robert Harvey Sep 16 '16 at 14:23

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 <(_ _)>


  • Thanks a lot, exactly my point! – Doc Brown Sep 11 '16 at 12:48
  • 3
    We asked if SE could change the site name and domain name first and then work out the details of the mod-editable changes later, but this is a one shot deal - everything needs to be done and in order and go live in one go. That means ironing out details like what the /tour, help/on-topic, and help/dont-ask will look like and a good definition of our scope that's understood by everyone here and the CM team. – Thomas Owens Sep 11 '16 at 13:07
  • 2
    =( OK, but then, after polishing the bike shed is 100% done, and it goes live,.. if it will happen so that we need to add/remove one bullet to the list, will they prohibit it? I think they'd allow it. Then, it basically means you can do it in more than just one shot, but you have to call it "bugfixing" instead of "multi-step shipping". =) This is kind of typical bureaucracy... Personally, I think that rephrasing the scope of the site is a result of scope creep, and the only useful thing is changing the name. But whatever, I'm ready for Follow-Up 4,5,6... – scriptin Sep 11 '16 at 14:24
  • 8
    @ThomasOwens I'm pretty sure no one cares about the minutia at this point. Just pick something, give it to SE, so this process doesn't take another 6 months. If people disagree they can come to meta. But at this point, my biggest frustration has nothing to do with irrelevant details but giving up faith that this change will take place. – enderland Sep 11 '16 at 15:12
  • 6
    @ThomasOwens: Ana wrote above "We're not being bureaucratic jerks for it's own sake" - honestly, it is hard to believe this under these circumstances. – Doc Brown Sep 11 '16 at 19:02
  • possible duplicate of this answer :) "We have already discussed this topic to death. We already have community consensus... get this change moving" (posted almost 2 months ago) – gnat Sep 12 '16 at 15:35
  • @gnat: you are joking, I hope? You don't want this answer to be closed because of that other answer ;-)? – Doc Brown Sep 12 '16 at 17:56
  • @DocBrown half-joking / half-complaining. As for dupe-closing (if any), it should be rather in opposite direction because newer answer does a better job of highlighting the issue (due to two more months passed since) – gnat Sep 12 '16 at 18:41

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.

  • 1
    "Development methods and practices" specifically refers to the software development process (think sequential models, incremental, iterative, spiral, lean etc.) and some other best practices such as TDD, DDD, formal methods, KISS, DRY. "Quality assurance and testing" (I, personally, am not a fan of "and testing" since it invokes the thought of writing and running unit tests, which tends toward Stack Overflow) refers to ensuring both process and product quality - quality assurance, quality management, and quality control. – Thomas Owens Sep 13 '16 at 23:32
  • I think that your bullets are OK, but the way I see it, the four bullet points are (1) how we go about plan and manage making a software product (or manage a software project), (2) the technical work that is managed to go from need to useful item, (3) ensuring the quality of the technical work, and (4) delivery of the high quality product to the client and user. – Thomas Owens Sep 13 '16 at 23:34
  • I also think that the four bullet points correspond to four categories of potential users, especially when you think of software that needs more discipline applied to it (like in a regulated environment, such as automotive, aerospace, or healthcare). The first bullet point goes to leads, managers, and process people (think IEEE and ISO standard people, Scrum Masters, and Lean and/or Six Sigma people). The second is for the hands-on technical people who build products. The third is for software quality (product and process - testers and auditors). The last is for configuration management. – Thomas Owens Sep 13 '16 at 23:39
  • @ThomasOwens: four points fine. five points, also fine. Three points as shown here, fine too. But if you can actually reach that SE folks directly, please, tell them lots of people here losing faith in how the site is managed by them. – Doc Brown Sep 14 '16 at 12:34
  • @Thomas Owens♦ "Development methods and practices" specifically refers to the software development process" I was not aware of that. I doubt people that misunderstood the scope previously will be aware of that either. Do you expect people to connect the broad term "Development methods" with some rigourous definition? – null Sep 14 '16 at 15:50
  • 2
    @null Yes, we'll be linking to related Wikipedia pages for all of the terms we use. The Wikipedia page that I linked to in my comment will be the one that is linked to by "development methods". – Thomas Owens Sep 14 '16 at 17:05
  • @Thomas Owens♦ sounds good! I guess Wikipedia is considered a reliable external source that's save to link to (no link rot)? Maybe consider linking to tag wikis instead. Although I have the feeling they are an abandok. – null Sep 14 '16 at 17:34
  • 1
    @null I'd like to link to tag wikis, but there are a lot of problems with them. They tend to not be as comprehensive as a Wikipedia article and don't have good history and attribution. My guess is there is a link between those two things (not to mention there's no incentive to write tag wikis that are good). – Thomas Owens Sep 14 '16 at 17:59

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.

  • 4
    Don't get me wrong, it is not that I think this is a bad idea in general. However, the drawbacks I see here are: 1) it will delay the process further - what I really dislike 2) it is coming a little bit late, the decision for new name and how it will be is made 3) setting up a useful usability test will probably be harder than you think 4) It is not worth the hassle - we lived for years with a bad name, and it did not kill the site - the new name will undoubtly be better than the old one, but if it is not perfect, then it is not perfect. – Doc Brown Sep 12 '16 at 11:32
  • @DocBrown I'm with you about delays being destructive. But usability testing should be a way to get the process unstuck, not slow it down, depending on why it's stuck. (I added four hypotheses about that to this "answer". Q&A is not a fitting format for this process.) A usability test could be done in a few hours after collecting or going to visit a bunch of candidate test subjects. – Jerry101 Sep 12 '16 at 22:28
  • 1
    per my observations amount of off-topic debugging questions depends more on network wide rate limit for new users and SE team can manage it as they wish. When this limit was zero Programmers were flooded. When they set the limit to 40 min things went back to almost normal. From this perspective site name change is there more to reflect and respect wishes of majority regulars – gnat Sep 13 '16 at 6:06
  • 2
    ...and when they increased limit to 90 min at SO but left it 40 at other sites this again resulted in uptick of debugging garbage here (noticeable but luckily not as bad as at zero limit). As if some of debugging lemmings who couldn't wait for 90 minutes discovered that they can dump their stuff at another site quicker – gnat Sep 13 '16 at 6:44
  • Thank you, @gnat! That's very illuminating. Since I seem to be an outlier -- the only voice in this thread interested in applying the concepts in the 4 bullet points -- I'm the misfit and will back out. As the community just wants a fancier site name, SE should make it happen without worrying about whether it solves a problem. – Jerry101 Sep 13 '16 at 19:54
  • 1
    I can't read minds of SE folks but it really looks like they decided to give name change a go after they discovered that managing off-topic debugging stuff that comes to Programmers is indeed easy with twisting that knob of rate limit. So if they want to make it look like success they simply increase that limit, and if they want it to look like fail they decrease it – gnat Sep 13 '16 at 20:01
  • 2
    @Jerry101: if you really believe you are "the only voice in this thread interested in applying the concepts in the 4 bullet points", you have probably not read the comments of the others very carefully. Here are lots of people caring about those points. They just don't think a full-blown "test-engineering approach" is the right thing to make progress. Actually, I agree to lots of the things in your rewritten answer - there is a huge communication gap between the SE responsibles and the community here - but this is not to be fixed by a usability test. – Doc Brown Sep 14 '16 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .