On 2020/04/05 10:23:50 Jacques Le Roux wrote:
> +1 for the idea, /contribute name is OK with me
>
> Jacques
>
> Le 04/04/2020 à 14:52, Rich Bowen a écrit :
> > Hi, folks,
> >
> > Over the last couple of weeks, I've been tackling the red boxes on
> > https://whimsy.apache.org/site/ with patches, and I've noticed
> > something. In almost every case, I have to hunt and hunt and hunt to
> > figure out 1) where the website source is, 2) where the project source
> > code is, and 3) how one is supposed to submit a patch/PR for one or the
> > other.
> >
> > Now, I'm not suggesting any kind of top-down mandate or anything, but I
> > was considering writing up a "best practice" kind of thing for
> > community.apache.org encouraging projects to have certain standard
> > elements on their project sites, so that it's easy for someone (let's be
> > honest, this is all about me) to go to a project site and immediately
> > know how to get involved.
> >
> > The first thing that I would like to recommend is that every Apache
> > project site have a /contribute page that contains the following elements:
> >
> > Where:
> >
> > Where is the project source code?
> > Where is the website source?
> > Where is the documentation source (if separate from the above two)
> > Where does the discussion happen? (Mailing lists, IRC, Slack, etc)
> >
> > How:
> >
> > How should one submit changes (ie, patch to mailing list? PR on Github?
> > etc.)
> >
> > What:
> >
> > What language(s) are used?
> > What framework (if any) is needed to build/test website/documentation
> > changes?
> > What should people consider working on? (ie, where do you keep your
> > tickets/bugs/TODO items?)
> >
> > Simple. Standard. In a consistent place. So that I don't have to spend
> > so much time hunting every time I want to fix a typo on a project site.
> > (I'm a big fan of "hackable" URLs, and knowing that I can go to, say
> > aardvark.apache.org/contribute and know there will be something useful
> > there.)
> >
> > Thoughts? Is "/contribute" the right thing to call this, or have you
> > seen it called something clearer elsewhere?
> >
> > I'll be starting with "my" projects, so that we can have some
> > example/boilerplate to point people to.
> >
> > (Yes, this is all part of my larger plan to have "best practice"
> > documentation that our projects can borrow/steal from. One of the things
> > that makes Apache so appealing to users is that they know what to expect
> > in terms of license and quality and governance. I'd like to extend that
> > to other aspects of our projects, so that there's a consistent(ish)
> > experience across projects. But we have to do this by leading, not by
> > compelling/requiring, because that's not how we do things.)
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
