We actively resist automating this process. Because of the way Etsy development is structured this gap gets fixed periodically and then we have to go back and un-automate it.

It's a key part of our 1st day push program: https://codeascraft.com/2012/03/13/making-it-virtually-easy-...

Also it would violate my first rule of engineering which is: "Never build a CMS"

Thanks for the explanation. Totally agree with "Never build a CMS" rule. But why not use a pre-built CMS in the first place? Either use Wordpress, or a CMS plugin for your framework if you're using something like ROR. If you're not using a CMS, how are you updating the copy on pages like About? Does that process require a developer each time?

The Etsy blogs use Wordpress, so we do use existing third-party tools where is makes sense.

Kellan might have a rule to not build a CMS but we certainly have built one to manage help page content and other knowledge base pages. That content is largely managed by our support staff.

I wrote the current tool but it is actively being replaced. We chose to to roll our own since we'd have to do some work to integrate a third party tool into our database architecture and authentication system. The tool is heavily integrated into other internal tooling and has specific workflows that also make using an existing tool challenging.

The About page content is largely static, aside from the staff photos mentioned in the above post.

can you explain this? i've always thought a CMS is a good thing to allow non-engineers to work with and edit non-critical data like this.

I think the point is "use existing technology" vs. "roll your own."

I assume it's more about understanding the processes. Once they understand how everything works, they probably just add the image to the code base and add an html tag to the about page. Nothing complicated, and it doesn't sound like they are really "coding" but it seems like the idea is more to give them some perspective on how the engineering team works.

One answer is that it's convenient to have the task around for engineer first-day deploys, which serve a greater purpose.

A second answer is building a database-backed CMS to replace editing html for every dumb page on the site would be a boondoggle and not an improvement.

That probably exists, too, but I think the idea is to expose folks in non-engineering roles to the code without it being overwhelming.

Indeed. I've seen this in academic labs as well that have a lot of undergrads exposed to research - deliberately keeping something undone, or less efficient than it might be to have an experienced postdoc do it, do that someone without a lot of experience can get their feet wet without having to try and tackle a full-blown project (coding or otherwise).

"This is what we do and how we do it" with a non-critical system that's approachable seems to be a great way to set up rotations.