(For the records, the entire process to get an extension deployed is at https://www.mediawiki.org/wiki/Review_queue as it's more than just Security.)

Can you be more specific about what you find confusing? The instructions state clearly that only the last one is required (in practise most projects only do the last one. I guess things have to be required to actually happen...)

Anyways, the first two are meant to be somewhat informal meetings where we just check you are on the right track. The concept review would be just to make sure your concept is sane. For example, if your proposal is to allow raw javascript on all pages, we would like to veto that right at the beginning. The design review is meant as a quick check-in to make sure your implementation plan is sane and to be able to make any suggestions. Its always best if we can give feedback early in the process.

The review for deployment is the formal review. Your extension should be done at this point, and we check it carefully. For examples of this look at the done column of Application Security Reviews as well as tasks with that tag that are resolved fixed.

)

I've attempted to flesh out the docs on wiki. Does that clarify things? Or are they still confusing?

@Lokal_Profil can this be resolved or is there something you are still missing from the documentation?

In case of doubt I would add this request to Developer-Wishlist (2017). The "worst" case scenario would be that the task is solved by the time it is voted. Not a bad problem to have. :)

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Thanks for the examples on the security review part. For me these are enough for that section.

The "Design review" section could still benefit from a few examples especially since it seems to normally consist of a more informal in-house meeting (or that is the outside impression at least). As such it is harder for someone outside of the WMF to figure out which documents they need to have prepared before etc. And examples bring this across better than just terminology.

To be honest, I think the "security design review" is more wishful thinking then actual practice. I don't think most projects actually undergo it.

If you're doing something relatively different from the average mediawiki extension, having a document saying this is what we want to do, and this is in broad strokes how we're going to implement it, would probably be useful. From your perspective, you probably want to tell us enough details so that if there is something to object to, we can object before you spend time doing it, not after. [I know that's not terribly helpful...]