[Owasp-leaders] Proposal for changing OWASP Documentation
jim.manico at owasp.org
Sun Feb 21 15:19:28 UTC 2016
Thank you for thinking through these issues so carefully, Kevin. These
are significant barriers to adoptions of this new methodology.
By the same token, the concerns and complaints about the wiki are very
just and something needs to be done to clean it up.
> ... but they have a process for dealing with it and part of that
involves an editorial staff. Is there some reason that their process
would not work for us on a drastically smaller scale?
Bingo. I have let this slide, but I think there is a lot more work we
can do to (1) enable editorial controls for new content and (2)
deprecate old and incomplete content. #2 is ongoing but I'll push more
on number (1) and get back to you on this as soon as I can.
On 2/21/16 12:07 AM, Kevin W. Wall wrote
> Sorry for jumping in way late here. But now that I've finally got a
> chance to read over the proposal at
> I have some comments / questions regarding the proposal:
> * Is the intent here for these new GitHub markdown pages to
> eventually _replace_ the OWASP wiki pages?
> If so, how do we intend to:
> -- Not break all the 3rd party inbound links to existing wiki pages.
> I'm not even sure that's possible unless the plan is to do some sort
> of auto-redirect.
> -- Be able to present a decent look & feel for PC browsers vs.
> mobile browsers.
> -- Replace the tabbed pages with what? AFAIK, GitHub markdown doesn't
> support that, at least out-of-the-box. If we had to
> "flatten" the presentation
> to account for all the tabs, I think that would look awful
> in most cases.
> If NO, then what exactly is the intent? To just provide more accountability
> in terms of who can edit what pages, etc.?
> * Wikipedia also uses wikimedia markdown and they supposedly have over 5M
> articles just for the English version and have over 10 edits per second. (See
> <https://en.wikipedia.org/wiki/Wikipedia:Statistics> for details.)
> Sure, they have
> disputed content, etc., but they have a process for dealing with it
> and part of
> that involves an editorial staff. Is there some reason that their
> process would
> not work for us on a drastically smaller scale? On the surface at
> least, it seems
> that such an approach might be more viable than a "burn it all to the ground"
> * I'm not quite getting how dumping (say) all the SQLi stuff together
> is necessarily
> going to stop the duplication. In theory, we could do similarly with
> Category tags,
> but if people are not diligent to first stop and check if something
> is a duplicate,
> I think a hierarchical organization will only help slightly. That's
> because for
> things like this, there are always multiple ways that we many want
> to view things.
> For example, presumably we would want all the cheat sheets organized together,
> all the vulnerabilities organized together, all the defensive
> frameworks organized
> together. But all of those would likely have cross-cutting SQLi concerns that
> need to be mentioned. So do we duplicate (say) the SQLi Cheat Sheet
> in multiple
> places? If not, then where would its home be, with the cheat sheets
> or with the SQLi
> Anyhow, just so things to think about. You probably already have, but maybe just
> didn't spell them on on the GitHub Documentation wiki page.
More information about the OWASP-Leaders