Re: /contribute on project sites

[Martijn Dashorst]

On Mon, Apr 6, 2020 at 1:58 PM Rich Bowen  wrote:

> On 4/6/20 7:51 AM, Martijn Dashorst wrote:
> > Would this be an acceptable /contribute per your criteria?
> >
> > https://wicket.apache.org/contribute/
>
> Indeed it is. It has all of the information that I'm looking for, and
> it's linked prominently from the main site navigation. It's *exactly*
> what I'm looking for!
>
> I have a similar page done up for httpd (although it's less detailed)
> and will be committing it later today.
>

Cool and thanks for evaluating the wicket page.

Martijn

Re: /contribute on project sites

[Rich Bowen]

On 4/6/20 7:51 AM, Martijn Dashorst wrote:

Would this be an acceptable /contribute per your criteria?

https://wicket.apache.org/contribute/


Indeed it is. It has all of the information that I'm looking for, and 
it's linked prominently from the main site navigation. It's *exactly* 
what I'm looking for!


I have a similar page done up for httpd (although it's less detailed) 
and will be committing it later today.


--Rich


On Sat, Apr 4, 2020 at 2:52 PM Rich Bowen  wrote:


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.)

--
Rich Bowen
rbo...@rcbowen.com

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org






--
Rich Bowen - rbo...@rcbowen.com
http://rcbowen.com/
@rbowen

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: /contribute on project sites

[Martijn Dashorst]

Would this be an acceptable /contribute per your criteria?

https://wicket.apache.org/contribute/

Martijn


On Sat, Apr 4, 2020 at 2:52 PM Rich Bowen  wrote:

> 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.)
>
> --
> Rich Bowen
> rbo...@rcbowen.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Re: /contribute on project sites

[Alicia Gonzales]

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

Re: /contribute on project sites

[Pierre Smits]

+1

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Sun, Apr 5, 2020 at 12:24 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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
>
>

Re: /contribute on project sites

[Jacques Le Roux]

+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