Re: [docs] Documenting YP processes

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2023-10-19 at 11:02 +0200, Michael Opdenacker wrote:
> On 19.10.23 at 09:40, Marta Rybczynska wrote:
> > On Wed, Oct 18, 2023 at 7:35 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > On Wed, 2023-10-18 at 16:57 +0200, Michael Opdenacker wrote:
> > > > Hi Marta
> > > > 
> > > > On 18.10.23 at 16:23, Marta Rybczynska wrote:
> > > > > Hello,
> > > > > I'm writing the "official" documentation for the YP security processes
> > > > > and I'm realizing that I do not know which document to put it into.
> > > > > There is no "YP Processes" manual. What about adding a "Security
> > > > > manual"? It can then include:
> > > > > - security processes
> > > > > - a single place describing how to submit CVE fixes
> > > > > - links to other manuals for relevant material and/or rewrites if necessary
> > > > IMHO, it does makes sense to create a new "Security Manual". We
> > > > currently have
> > > > https://docs.yoctoproject.org/dev-manual/vulnerabilities.html with some
> > > > useful details contributed over time, but a separate manual would
> > > > probably get more of the attention this topic deserves.
> > > I'm torn between a security section in the Development Manual or a
> > > separate one. I don't think we want too many manuals so I have a slight
> > > leaning to a section but am open to persuasion.
> > > 
> > Arguments for both options below. I do not have a strong opinion, while
> > Security Manual seems to me a little better option at this stage.
> > 
> > In Development Tasks Manual
> > - puts everything in one place
> > - security is a part of a standard development process
> > 
> > Separate Security Manual
> > - more likely to be found by people who do not consider themself
> > developers ie. security researchers, analysts who have a fix etc
> > - more general visibility (when searching by keywords), can be
> > announced by the project
> > - better fit for processes (Development Tasks Manual is strongly
> > technical and concentrates on tools)
> 
> 
> I don't want to vote twice, but your argument for making it more 
> accessible to people who don't consider themselves developers sounds 
> pretty strong to me. The better visibility is quite strong too.
> Other opinions?

My concern is whether there is enough content for a dedicated manual. I
know it often feels like there is but when you write it down, I think
there is a lot less than it feels like there is. We should have a
relatively high bar to a new manual. Perhaps we start with a section
and then migrate to a manual if it feels like there is enough content
to make sense?

Cheers,

Richard