Last month's announcement about our updated criteria for graduation and site closure sparked some solid examination into the intended nature of public beta and graduation.

One thing these discussions showed us is that, contrary to what the Community Team had long believed, getting a custom design is just one of several reasons folks want their sites to graduate. Our assumption was that a design was the only real incentive; we were wrong. It is indeed a big, exciting moment and a thing we will continue to invest resources in, but there are other aspects of graduation the community is interested in independently.

We also considered that although we're hiring designers as fast as we can, our design backlog still isn’t going to disappear overnight. Long story short, if we have stuff besides designs that our set-to-graduate sites want and can give it to them, maybe we should!

In keeping with your feedback, we’re considering laying out the mechanics of graduation a little differently in the coming days. It would look like this:

The Community Team announces that a site is cleared for graduation. Without delay...

  • the beta label is removed
  • elections are held
  • migration paths are set up
  • community ads are run
  • a link to the site is added to the footer

...Then, as it becomes available

  • the site gets their custom design.
  • privilege thresholds are increased to graduated site levels

Note: We propose keeping the lower privilege thresholds in place until designs are ready because we think raising them without giving you something to celebrate just wouldn’t be that much fun.

We hope this approach will be smarter, and more encouraging than the current state of affairs. I want to be upfront in saying that we don’t yet know how soon we can implement this because we’re looking for community feedback here first. If there’s broad support for this idea, then we’ll figure out the technical details and let you know.

What do you say, should we give design-independent graduation a try?

EDIT: That was a nearly unequivocal YES, so we're going to figure out how soon we can put this into practice. More to come!

  • 151
    "So, should we give design-independent graduation a try?" Yes. You should. Preferably starting yesterday.
    – Undo
    Commented Jul 15, 2015 at 17:28
  • 1
    @HDE226868 I said above, I can't give a time estimate yet simply because we're checking whether or not people would want this first. That said, the idea here is to get you good stuff faster. :)
    – Ana
    Commented Jul 15, 2015 at 17:34
  • 6
    I can't think of any negatives of why not other than "but Sally got to have ice cream with her cake, why can't I, waaaaa waa" , and I don't see any negatives in your question or anywhere else. So yea, just do it.
    Commented Jul 15, 2015 at 17:39
  • 3
    Thanks for recognizing my question about this. I really do think this is a great option and I don't really have anything to add to what I've already posted in that feature request.
    – Catija
    Commented Jul 15, 2015 at 17:49
  • 2
    Some Sites need the privilege thresholds increased to graduated levels. is that an option on a site by site basis?
    – Malachi
    Commented Jul 15, 2015 at 21:13
  • 3
    Love it, perfect. I especially like how you've put privileges with site design (though possibly for another reason, I think some of the beta sites are just a bit harder to get experience on. We're serious about our site, we're just not SO...). So, for whatever my opinion is worth I say "yes please!".
    – Jae Carr
    Commented Jul 15, 2015 at 21:59
  • 4
    There's one big question I'm not sure this really addresses... It seems that Robert C.'s preference is to remove the concept of "graduation" and simply have Proposals, Betas and "Sites". With the Beta logo removed after the site has become "stable" after about 6 months... But, there's a huge difference between these stable sites and the sites slated for graduation. My understanding of your previous post is the plan to remove the "sword of Damocles" from over the heads of low-volume sites so that they're not worried about getting closed but they may still never "graduate".
    – Catija
    Commented Jul 15, 2015 at 22:00
  • 2
    @Catija My proposal provides a step in the direction of Robert's model, but changes fewer things so that we can observe their effects more easily. In other words, we're being iterative about it. You bring up some important ideas in your comment above. Care to start a new meta question and link to it here?
    – Ana
    Commented Jul 15, 2015 at 22:15
  • 4
    Has the team looked into automatically scaling reputation thresholds to meet demand?
    – user206222
    Commented Jul 15, 2015 at 23:15
  • 1
    @Emrakul That would super-confusing to multi-site users. "I have 1500 rep on these two sites; can I edit posts there? On this one I can, on another one I can't but I could yesterday..."
    – user259867
    Commented Jul 15, 2015 at 23:42
  • 1
    @1999 "You must have 1750 reputation to close posts." Don't disable the controls, but give a helpful message when someone engages them, like SE does with voting.
    – user206222
    Commented Jul 15, 2015 at 23:54
  • 9
    I'm not keen on the privilege thresholds not changing with *semi-*site-graduation. If the site is going to graduate design-independent, the rep should graduate as well. Reading through the posts below, a lot of people agree with this philosophy. Commented Jul 15, 2015 at 23:55
  • 3
    @Emrakul I can't remember ever discussing it with anyone else, but when I've considered the idea of scaled rep thresholds on my own, I've always ended up where 1999 did: it would be crazy confusing to have inconsistencies from site to site (not to mention from month to month or day to day on the same site). If you can think of a way to solve that problem, I would be all ears.
    – Pops
    Commented Jul 16, 2015 at 1:31
  • 3
    That's not an unequivocal "Yes". There is huge support for progress in this area, but the proposed change is not the design-independent graduation that we are looking for. With this proposal, we're still at the mercy of the design team to clear their backlog before real graduation happens. Commented Aug 15, 2015 at 3:02
  • 6

13 Answers 13


I say do it. Why?

Because you lose nothing, and gain a lot

People on beta sites tend to lose interest after a while - there seems to be a natural drive to get the 'beta' label off the site. It almost feels like a bad thing, and people start asking what they need to do to get rid of it. More importantly, they were promised that if they do everything right the label will go away... and it hasn't.

By doing this, you move the thought process from:

"we're doing something wrong, obviously, but we have no idea what and those CMs aren't telling us. They obviously hate us."

(which is very very frustrating to some folks), to:

"oh, the team doesn't have enough resources to get us colors yet, but we can have elections and other shiny toys. Hrm okay"

  • 26
    . . . of course eventually people will riot over the design team not having enough resources to get to them, but I think taking the perpetual BETA label off a site is still a Good Thing. If nothing else it signals to the rest of the internet "This site is sticking around."
    – voretaq7
    Commented Jul 15, 2015 at 22:04
  • 33
    I agree with this as well. However I think -on top of removing the 'BETA' label- there should also be a theme change to a standardised, 'graduated' template. No, Not a custom design that fits the site, but at least some way (other than the title) to distinguish a 'beta' site from a 'graduated' one. That way we can 'graduate' sites into a Standard, 'SE-esque' design, and worry about the custom stuff later.
    – Robotnik
    Commented Jul 16, 2015 at 8:00
  • 4
    Bring Sketchy back for true betas, @Robotnik?
    – TRiG
    Commented Jul 16, 2015 at 8:30
  • @TRiGisTimothyRichardGreen, Robotnik - good idea. :-) Commented Jul 16, 2015 at 12:37
  • 9
    Reminds me of how a house that's been on the market for very long but not sold has a hard time selling. "Why's that house still not sold? What's wrong with it?" --> "Why's that site still in beta? What's wrong with it?"
    – hBy2Py
    Commented Jul 16, 2015 at 14:03
  • 4
    I say keep it simple. 1) tell the community they are being considered for graduation every time they are. 2) Tell them the result, with encouragement and honest feedback if they miss ("we just need a wider variety of questions to graduate!" is more motivating than "have they forgotten us? are we going to be deleted?"). 3) If they pass, simply remove "Beta" and add a "We're graduating" sticky featured meta post that sits in that box on the right on the main site, 4) The design is the end of the graduation process, not the beginning, kinda like the graduation ceremony. Graduating. Commented Jul 17, 2015 at 23:03
  • 1
    @user568458 I really like the idea of "The design is the end of the graduation process, not the beginning". Also, I like the idea of a cooler generic design for graduating sites.
    – yo'
    Commented Jul 19, 2015 at 15:36

I think the concept is great, but the motivation for the privilege levels is somewhat flawed.

It should perhaps be considered on a case-by-case basis, but the privilege threshold is one of the key reasons why, for example, I wanted Code Review to graduate.

Escalated privilege thresholds is a good thing for a site - it encourages people to be more thoughtful about their contributions, it gives additional goals to strive for, it is a motivator.

In addition, it keeps people new to the site out of situations which can cause them troubles.

The reasons beta sites have lower thresholds is because nobody has high rep. If the site is stable enough to be called "mature", if the site is competent and capable finding and electing moderators, then they are equally capable of having trusted users, etc.

The delay for the implementation of the threshold is likely to cause as much damage for some sites, as good for others. At a minimum it should be considered on a site's merits.

Apart from that, I think this is a great stride forward for Stack Exchange

  • 9
    I agree; I'd like somebody to look at some data (like what happened with sites where levels were already raised at graduation) and figure out roughly what distribution of users over rep is needed to support the higher levels. Then when a community is there, it's probably time to raise them in advance of the design. (The design should be the last thing because, hey, shiny.) Commented Jul 15, 2015 at 19:48
  • 44
    Yes. This was the subject of a fair amount of internal debate, and if it hadn't been brought up by rolfl (or someone else), I would have posted an answer of my own. We already look at "can the site sustain an election?" and "can community moderation work effectively after privilege levels increase?" as graduation criteria. Given that, and the fact that we're now acknowledging that people care about much more than just site design when thinking about graduation, continuing to tie privilege levels to design feels very backwards. Associating with elections would make more logical sense, to me.
    – Pops
    Commented Jul 15, 2015 at 20:20
  • 9
    privilege threshold could be decided based on number of active high rep users so they can maintain the queues IMO. Commented Jul 15, 2015 at 21:59
  • 4
    This pretty well encompasses my feelings on the proposal. Some threshold level has to be established for determining when to raise the privilege thresholds to "graduated site level" - I'm not sure what that is, but I do think it's logically independent of "custom design". I almost want to say as soon as the beta label comes off some bump to the privilege thresholds should be made - even if not right to "fully graduated".
    – voretaq7
    Commented Jul 15, 2015 at 22:00
  • Yes. This. There's no reason to hold off on raising the rep levels. They have a lot of impact on how the site is self governed and have nothing to do with the way a site looks. If a site is ready to graduate, it's ready for stricter rep requirements on prilidges. It may be worth investigating a two stage increase though @pops, for sites ready to graduate but still small in comparison to others.
    – RubberDuck
    Commented Jul 17, 2015 at 2:26
  • 1
    @RubberDuck do you have any examples of sites that are advanced enough to warrant graduation but small enough not to be able to sustain the higher rep thresholds? Off hand I would expect that a site that doesn't have enough active high-rep users isn't ready to graduate. Commented Jul 17, 2015 at 2:38
  • 2
    Actually @MonicaCellio I think Code Review may be a good example. We're ready to graduate and we really do need the higher rep requirements, but I fear they're a bit too steep. Not all of the very top users are still active, so the number of users with delete privileges would be small. We may have to rely on mods for deleting crap.
    – RubberDuck
    Commented Jul 17, 2015 at 2:43
  • 1
    I see 11 >20k users (two of them mods). I know you said they're not all active, but for comparison, I think The Workplace had five at graduation. You should be ok with community deletion of answers, and community deletion of questions only requires 10k so you should be fine there unless most of your high-rep users are inactive. Commented Jul 17, 2015 at 2:46
  • @MonicaCellio 4 of that 11 are mods and only 2 or three of the remaining 20k+ users actively moderate. Idk. We'll see. Knowing that about workplace makes me feel better, but I still just don't know.
    – RubberDuck
    Commented Jul 17, 2015 at 9:44
  • 4
    @RubberDuck - there is very little that needs to be done in terms of community moderation that requires the 20K rather than the 10K level. Those things that look 'useful' are still possible through flagging, or review queues. The 20K threshold is more about convenience and efficiency for the user than raw functionality.
    – rolfl
    Commented Jul 17, 2015 at 11:25
  • 3
    Fair enough, but I still think since we will now have betas, "long term" betas and graduated sites, a mid-level stage for privilege rep levels may be wise. We might not have been in such a hurry to graduate if the functionality had been adjusted a bit.
    – RubberDuck
    Commented Jul 17, 2015 at 11:31

Dropping the site design change from the graduation package is understandable. It is obviously a large amount of effort to draft, consult, and implement a design. I agree that lack of a site design is a poor excuse for holding back the growth of a site. I've lobbied hard for this proposal for a long time…

… with one difference: the privilege levels need to be raised too. If privilege levels aren't being raised, then it's not a true graduation. The site design is cosmetic and thus optional; the reputation thresholds are neither cosmetic nor optional. Using thresholds that are supposed to be appropriate for a new sites on a mature site is harmful. Dropping the threshold change from the graduation package is demeaning.

I assume that with the exception of the site design, all of the changes shouldn't take more than a few hours of work to implement. There is therefore no reason not to give graduated sites everything but the site design.

If you want to give users something to celebrate, I suggest that you apply a generic graduated site theme that is different from the beta theme. If the design team is too busy to do even that, though, then let's drop even that request — Code Review wants this done yesterday!

  • 16
    The "Beta" part of the logo could at least be removed.
    – nhgrif
    Commented Jul 15, 2015 at 19:10
  • 17
    Literally yesterday: elections ended yesterday. Commented Jul 15, 2015 at 19:13

Great idea. I'm all for it. And I don't want to repeat other answers saying that. I just want to add one teeny, tiny tweak:

Along with removing the "beta" label, change the site logo and base design in some visible way. Graduated-but-not-yet-designed sites can all share the same different style, and the change doesn't have to be large (maybe just a change of color scheme), but it would help to do something.


  • People who've visited before see "oh, this is different -- not like that three-month-old beta I was just looking at". Make it a little more prominent than just removing the word "beta".

  • In contexts where all we have is the site logo -- the supercollider list, browser tabs, network profile, tweets, etc -- there's something to convey "not a beta". When I'm scanning one of these lists for a site my universe is currently broken into two groups: blue backgrounds with white characters, and everything else. It'd sure be nice if a newly-graduated site could be part of "everything else" (or, more realistically, a third group).

This doesn't have to be complicated -- maybe just change the hue (blue -> green?). Or, now that betas are back to being shorter betas, bring back the "sketchy" theme for them and use the current beta theme for newly-graduated sites? (That might be harder because of base CSS, though. Just an idea.) I trust the design team to come up with something that works and that wouldn't require weeks and weeks of work to implement.

  • Or maybe just a tweak to the font-stack? ;)
    – Dɑvïd
    Commented Jul 16, 2015 at 7:24
  • 5
    @Davïd that too, but just that would probably not provide enough signal to casual visitors, so also a theme change or something of that sort. And definitely the icon; that shows up alone in a bunch of contexts. Commented Jul 16, 2015 at 12:36

What do you say, should we give design-independent graduation a try?

I think that the design is the least important when graduating a site. If a site is ready, just let it graduate. Why hold back? I can't think of a valid reason to not let the site graduate.

Maybe it is useful for a site to see its 'implementation timeline', something that shows where in the process the site is, call it 'transparency'. This would prevent questions like 'but why is this there, but not here?', etc.


The recent elections on Blender, Network Engineering, Cryptography and Code Review (all betas) went reasonably well. On some of these the number of candidates was barely enough to hold an election, but that might be attributable to a glitch with election notifications, which was since fixed.

So, I support the idea, but suggest the following process:

  1. Mod election is announced.
  2. If the election takes place (and not called off for lack of candidates or another reason*), then after it concludes, graduation is announced, and the perks are enabled.

*Some of the elections had double-digit voter turnouts. What if it was a single-digit number?

Tangential: the recently fully-graduated sites (Biology, Chemistry, etc) haven't got a link in the footer, so I'm not sure what chance the partially-graduates sites have for that.


As someone from an SE that was announced as ready for graduation about 10 months ago and has not graduated yet, this is a very good idea and is very important to the sites that are ready to graduate, but can't yet because of the backlog.

The long term users of Music SE know that we are in the queue to graduate, but we've also gotten a lot of new members to our community since then and it's not obvious to them that we are going to graduate any time soon. Even some of the users who visit the site every day and are watching other sites graduate are getting antsy about when we actually will graduate even though it was announced including myself.

Just simply dropping the beta status and starting to give us features of other graduated sites goes a long way in this as it show we're graduating or on the path to graduation for everyone.


I think dropping the design dependency is a GREAT IDEA!

It is an exciting step for a site to move on and not have that nasty Beta tag attached to their moniker. Awful, I tell you, just awful!

One thing I'd like to mention which may help with the design dependency is this. With all the gorilla coders and design freaks we have around here, why not offer up what exactly is needed for the design items and I bet you'd have people beating down your door to help you at no charge. This would do the following:

  1. Alleviate the backlog.
  2. Allow the design dependency not to be a big deal.
  3. Get complete buy-in from the graduating site.
  4. Provide more excitement for the entire SE network.

I know not everyone would be up for this, but I think if you were to talk to the mods on the soon to be graduated sites, they could make it happen. I personally can see a lot of the design elements which need to be changed, but I'm sure I'm not seeing all of them. If a complete list of these items were published, or at the minimum, were given to the mods of these sites, suitable design people could be rounded up from the communities at large and the tasks would be completed. It may be that what is produced might not be completely usable, BUT, it would probably get it to a point where only tweaking would be necessary for the completion of the design. Would site graduation still need to be dependent upon these? Not at all, but it would bring the excitement and community involvement into the mix.

Now, I get it if you run a Union shop ...

  • 4
    +eleventy on getting the community to contribute to the site design!
    – FreeMan
    Commented Jul 15, 2015 at 22:37
  • 15
    Sorry, but I do not think that a community-driven design or bottom-up design can work (let alone design by committee). You need to start with a big concept and then realise it in detail; you cannot start with the details.
    – Wrzlprmft
    Commented Jul 16, 2015 at 7:15
  • 2
    @Wrzlprmft - You sound like all the bureaucrats I have to deal with on a daily basis. Do you think there aren't any technically or design savvy people around SE who don't work for SE? You've got a world wide community of coders, designers, people, who are more than willing to get the job done. SE would still have final say. What I'm suggesting is there are people who are willing to get the leg work done, then turn over what they have to SE for final say and publication. It's just a way to speed up the design process. Commented Jul 16, 2015 at 10:06
  • 4
    @Paulster2: While designing involves some legwork that you may possibly crowdsource, this legwork comes in the end. In the beginning you need to formulate a coherent concept and this is something that should be done by a few, able people. Sure, some sites may have such people and they may be even willing to do this work, but there is no way to guarantee to entrust this work to these people and these people only. Others who think that making a good design is easy and have no idea what they are doing will want to have a say in it and this is bound to end in discord.
    – Wrzlprmft
    Commented Jul 16, 2015 at 19:35
  • 3
    This is another idea that's been tossed out a few times now on various metas. We've chewed on it a little but haven't made any Official Decisions yet. Just speaking for myself here: I'm reminded of the giant naming brouhaha of 2010, which I watched as a regular user. There were good arguments on both sides of that debate, and as much emotion as I've ever seen on Stack Exchange. I'm concerned that crowdsourcing design elements might open up something akin to a second round of that turmoil, albeit even more acrimonious.
    – Pops
    Commented Jul 16, 2015 at 20:40
  • 1
    @Wrzlprmft having a list of required details doesn't prevent a community from suggesting overarching design concepts and then voting on which to use. A list of details doesn't force a bottom up approach. Commented Jul 16, 2015 at 22:06
  • 2
    @trichoplax: A list of details doesn't force a bottom up approach. – But it does not encourage it either. You need far more than such a list to guide a community to produce a design that you actually would want to replace the Beta design. If this can be done at all, developing and establishing such a process and guidance would take very long to amortise.
    – Wrzlprmft
    Commented Jul 16, 2015 at 22:34
  • 1
    @Wrzlprmft point taken - if the community doesn't already contain the people required to guide that process then it's more of a drain on staff than the time it's meant to be saving. I can see this working for some sites, but rolling it out to all sites would probably cause more problems than it solves. Maybe individual sites can raise it if they can demonstrate capability? Commented Jul 16, 2015 at 22:35
  • @Wrzlprmft - While I understand your point, you make it sounds as though SE has not been through the rodeo of designing a site before. I'll guarantee you they have a formula for creating the site design. This is all of the In the beginning you need to formulate a coherent concept which you talk about. It's the leg work which needs to be done. Commented Jul 20, 2015 at 12:54
  • @Pops - Ayup ... I can completely understand and see that happening. This is the reason I suggested SE would have the final say. I can see the effect of design gone wild, lol! Commented Jul 20, 2015 at 12:55

Great idea. You have much to offer in allowing a site to graduate. In my personal loose order of priority, with an estimated amount of time you have to invest in parentheses

  • definitely first removing the beta label and giving a huge sense of security to the community and the rest of the internet
    (2 mins, a meta post saying "Congratulations! You made it!")

  • bug fixes that are particular to a community (internationalization, etc.)
    (several hours of developer time, but possibly less if you allow the community to help)

  • moderator elections (10 mins developer time)

  • Community Ads
    (10 mins developer time)

  • ...

  • definitely last a shiny new design
    (possibly weeks of developer time)

Work in order of the list, just ensure that you scale your hiring to get to the last step eventually. (I still think a nice shiny design is an important last step, not at last for presentability and for the Stack Exchange image.)

In fact, some unofficial comments which give a "tentative list for graduation" are already floating around the network, but they don't have any of the good reassuring effects. Why not make them official? (It's not like people are going to say, "oh, we're graduating? I guess I can take some time off now...". Everyone's excited to be here already.)

Maybe keep an updated public list of individual progress of recognized-graduated sites. We all know you have many priorities and making a site design shouldn't be your first priority and we won't be angry if you run a bit behind schedule (because you're low on staff or because you just haven't found the right guy/girl for the job).


I completely agree with this. I also agree that an increase of reputation is key. Having participated through more beta sites than just about anyone (Via Area51 badges), I can state for certain that after a time, you have a core group that is running the site, and it takes a while to build up to that core group. If the group exists, then it's frustrating that someone with relatively little knowledge can do relatively heavy moderator hitting.

I do like the idea of a few changes, perhaps a standard design, and possibly a custom color changes for the given site. This is optional, however. Just make sure to get rid of the word "beta" for certain!

Of course, I also recommend that this change be enacted slowly, no more than a site every week or two, so that the SE staff doesn't have too much to handle all at once. But I think this will really work.

  • 2
    I agree with everything except the "slowly" part. The process has been slow enough as it is, and these changes are way overdue. Commented Jul 16, 2015 at 19:47
  • The staff arrive have to do elections which will take time. Maybe a bit slow at first, then supposed up as possible. Commented Jul 16, 2015 at 20:46
  • 1
    By my count, there are approximately ten sites that are ready for graduation but are waiting on artist time.
    – Mark
    Commented Jul 18, 2015 at 0:18

Graduation entails many things, which it made sense to group back when sites were supposed to graduate or fail after three months:

  • Remove the sword of Damocles of shutdown.
  • Give the site its own name — but we aren't doing that after all.
  • Give the site a distinctive visual look.
  • Remote “beta” from the site description, which in itself gives a feeling of accomplishment and permanence.
  • Moderator elections.
  • Migration paths.
  • Increased privileges.
  • Mention in the footer of other graduated sites.
  • Swag!

When betas can last years, it doesn't make sense to group all of them in one package.

Moderator elections should happen when the community is large enough to sustain them.

Migration paths should be enabled when policies have settled. Typically, a few months is enough, but this needs to be studied on a case-by-case basis.

“Beta” carries the implication of something unfinished, with a risk of failure. So the beta qualifier should be removed when the site has reasonably well-defined and stable policies, and has shown a steady growth or has shown to capture a significant part of its target audience. This may not involved getting 10 questions per week! Many Stack Exchange sites (Skeptics, Theoretical Computer Science, Cooking, …) are perfectly healthy with far less than 10 q/week.

Tying mention in the footer to graduation is odd. Why hide a site when it's trying to grow? Beta sites should be mentioned in the footer as soon as they appear in the hot questions list. Which, currently, is from the start of the public beta.

Raising privileges can happen when there are enough users across the larger privilege brackets. However, raising privileges is a penalty for users in the 125—20000 reputation range, i.e. for all but the top users who use the site more than occasionally. So it should only be done if there's some reward to compensate. Raising privileges should be done either when the “beta” qualifier is removed or when the site gets a new design, I'm not sure which.

Site-specific swag has to follow design. Is swag even done these days?

Therefore things should happen roughly in this order:

  1. Mention the site in the footer as soon as it's public. (Or later, but if a site is ready for hot questions, it's ready for the footer.)
  2. When a site pair has a stable policy that questions about $topic are off-topic on A, on-topic on B, and the community on A has a good idea when questions on this topic are ok for B, enable the migration path following a meta discussion on both sites. “No migrations for beta sites” made sense when beta site meant fluctuating policies, but that reasoning is long obsolete.
  3. When a site has enough of a community to sustain elections (I don't know how to quantify that, this should be a separate election), run elections.
  4. When a site has become stable enough and has sufficient audience, declare it graduated: remove the beta label.
  5. When you get around to it, give the site its own design.
  • "Is swag even done these days?" - It was claimed to be done some months ago, but currently nobody really knows. Commented Jul 20, 2015 at 4:21
  • By the way, as a recipient of swag from ELL's graduation, I can assure you that swag is still being handed out. (cc @ChristianRau) Commented Apr 25, 2017 at 17:08

One other suggestion is, like the banners for the website, to give the users a chance to showcase what they would like the site to look like.

Some websites, where there aren't many programmers/designers, may only require a free-hand drawing of the desired style. (Trust me, it is easier to have a drawing that doing everything by yourself.)

Other websites, with designers and/or programmers, may show their ideas.

The winning idea would be the one that is implemented, and with an award. Some merchandise would be a do-able idea. It saves you money, time and non-material resourses.

This is a win-win situation. I can't see how StackExchange would lose with this. And everybody has the look they like and want on their website.


I'm sorely disappointed and am afraid you've got it all backwards.

Let's review the sequence:

  • Stack Exchange pursues aggressive Area51 policy with frequent formation of new "beta" communities (no direct link at the moment, this question outlines the process).
  • Site design queue grows.
  • Design bugs go unnoticed and unacknowledged.
  • Stack Exchange announces change of criteria for graduation and promises partial perks for sites too long in beta (including custom design elements).
  • Now, Stack Exchange drops the idea of custom design elements but claims it is a huge step forward.

Translated from PR-speak, this reads as follows:

"Our design team is too creative to pay back technical debt and too small to keep our past promises. Thus, we no longer promise you any custom designs."

Please, be sincere with the community. You are choosing the path of least resistance, and it doesn't bode well.

What can be done realistically? I can see various alternatives, yet they haven't been pursued so far (some have been rejected for a bunch of reasons).

  • Scale back on new site formation?
  • Force the design team to open bug database to read-only access from the community?
  • Open-source/crowdsource site design? (see Paulster2's suggestion above)
  • Set up a rigid, community-accessible schedule for site design?
  • Hire more designers?
  • Switch some of the more graphically gifted developers from adding new features (StackEgg, anyone?) to fixing the design and technical debt backlog problem?
  • ... to be continued ...
  • Your writ makes the assumption the design team and the development team are one in the same. While bugs should be fixed, why do you think it's interdependent? Commented Jul 15, 2015 at 22:24
  • "Force the design team to open bug database to read-only access from the community?" - What, exactly, would this do?
    – Andy
    Commented Jul 15, 2015 at 22:27
  • 2
    @Paulster2 - these are design bugs. Not functional back-end bugs. Commented Jul 15, 2015 at 22:28
  • 2
    @Andy - transparency is a great incentive. Commented Jul 15, 2015 at 22:29
  • 8
    The "bug database" is meta. IIRC SE doesn't have a bug tracker. There are Trello boards, but do you really want to make people work in a fishbowl?
    – Undo
    Commented Jul 15, 2015 at 22:29
  • 2
    I don't think the argument "there are still issues so don't do anything new untill they're fixed" is pretty bad...
    – Tim
    Commented Jul 15, 2015 at 22:30
  • 1
    @Undo - maybe SE should admit that not everything can fit into a Q&A model :) Commented Jul 15, 2015 at 22:31
  • 17
    This seems unrelated to the OP (which, by the way, does not "drop the idea of custom design elements" as far as I can tell). Why don't you make this post into a separate feature request? Or, better, propose one such idea at a time to get feedback. Personally, I doubt second-guessing the work ethic of designers or the number of designers hired is going to get you anywhere.
    – Frank
    Commented Jul 15, 2015 at 22:31
  • @Tim - there should be some balance, I agree. Commented Jul 15, 2015 at 22:32
  • 1
    @Frank - I'm not second-guessing. Please read the official reply. Commented Jul 15, 2015 at 22:34
  • 1
    @Andy - exactly. You can find them in one place, run stats on them, see who does (or at least, should be doing) what. With a meta for a bug tracker, there's no traceability and no accountability. Commented Jul 15, 2015 at 22:38
  • 19
    This seems as good a place as any to reiterate that we are actively looking to expand our design team. If you know anyone, please send them our way!
    – hairboat
    Commented Jul 15, 2015 at 22:39
  • 2
    @DeerHunter Nah - Ana already mentioned it in the OP; it'd be redundant.
    – hairboat
    Commented Jul 15, 2015 at 22:43
  • 9
    @abbyhairboat Why not advertise on your own site? Commented Jul 15, 2015 at 23:28
  • 2
    @Andy "The problem isn't that they can't see them. It's that they are understaffed in this particular area" - Ok, granted. But more often than not, I simply don't really know if they can see them at all when they're barring any kind of response from the team, be it just a short "oh yeah, we noticed". That would already be sufficient to know that the problem actually is that they are understaffed and not that they're not being aware of the bug at all or decided to not care about it. I don't want to assume they ignore stuff (and I don't believe they do), but frankly, I just don't know. Commented Jul 16, 2015 at 12:06

You must log in to answer this question.

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