I'm fine with the screen's corner radius and okay with the ears, but I really really really wish the inner-top corner radius of the ears matched the bottom corner radius of the sensor area. Having the inside of the ears with a tiny radius at the top and this big swooping curve at the bottom just looks weird.

That said, that's a minor niggle with what looks like so far a really visually stunning phone.

There isn't really a set of rules that instantly makes your product 100% inclusive and accessible. You could probably make up a set of guidelines that help, but even with them it's important to be able to understand the perspective of people that are different to you, and have them in the back of your mind when you're building your product. Doing this requires listening, reading and learning about the experiences of people who are different to you.

It's also worth keeping in mind that inclusivity matters at every level of your product. Does your data model restrict users from changing their username, forcing someone to log in with the surname of their abusive ex-husband? Does your feature set allow users control over how much access strangers have to them? Are colourblind users of your product missing important information because of your UI? Does your marketing make potential users feel like your product isn't meant for them?

The last thing that's worth remembering is that inclusivity is about more than just race and gender. I've already mentioned colourblindness; dietary requirements is one you need to think about if you're running an event; and so on. Plus, not everyone in a group thinks or behaves the same way, and some people belong to more than one of the groups you need to think about.

Not a company as such, but Django's documentation is very well written. Jacob Kaplan-Moss has a really great article about it (part of a series) which I think sums up what makes it so great.

The layout of the docs could be better, though, especially when it comes to the reference documentation. I find that I want to jump around a lot when I'm reading the Django reference docs, and the navigation doesn't really accommodate that as well as, say, Stripe (which has already been mentioned). The downside of the Stripe layout, though, is that the reference is so much different to the prose documentation, so it feels weird switching between the two.

Git is a Conservancy member project. It serves the same purpose for Git and a bunch of other projects as something like the Python Software Foundation does for Python, which includes accepting donations, and those donations go back into Git itself.

I'm glad you've removed the donation links.

It worries me a bit that you've got a website that looks like it's trying to pass itself off as the official Git website, that's soliciting donations for some mysterious entity called "DVCS" that isn't the Software Freedom Conservancy (the Git project's stewards).

It would probably be a very good idea to be clear on the home page that your site isn't the official site of the Git project, and be more clear about where the donations you're soliciting go to.

From the description:

(ignore the kerning.. this is just a photo of an early print test)

The southern cross is a good symbol on it's own (although I do feel like it's been co-opted a bit by racist bogans, along with the current flag itself) but the current Australian flag looks just like any other former British colony. It'd be nice to have a flag that actually has our national colours on it, too.

Actually, while we're on proposed flags, I like the New Zealand "Red Peak" one too, although it doesn't feel as iconic as the Canadian flag is or Golden Wattle could be.

I'm a big fan of the Canadian flag. It's simple, unique and instantly recognisable.

There's a proposed flag for my country of Australia, the Golden Wattle flag, that I'm quite fond of for the same reasons:

Even if you think all the usual security/privacy benefits of HTTPS don't apply to your portfolio site, there's also this: having HTTPS will prevent unscrupulous ISPs from injecting ads into your site's pages.

Even if the image is identical at every size, srcset is also going to give you more reliable results if you don't know what the image will be beforehand (e.g. making a template page that's going to get loaded into a CMS), because you can't tweak the compression settings and then check the results to make sure your images aren't ruined.

Tweaking compression is also not an option for the sort of images you'll want to load as PNGs (e.g. logos), although if you've got lots of blocks of solid colour a @4x PNG might not be much bigger than the @1x, so you might as well just serve the @4x. (Yes, there are phones which use @4x; not tablets or desktops yet though.)

That said, for most of the cases where you want a PNG, you might really want a SVG (remembering that SVG files are uncompressed XML, so you need to make sure your server is set to compress them with gzip or brotli, and look at what the file size is then).