You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Rich Bowen <rb...@rcbowen.com> on 2020/04/04 12:52:37 UTC
/contribute on project sites
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
rbowen@rcbowen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: /contribute on project sites
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Apr 6, 2020 at 1:58 PM Rich Bowen <rb...@rcbowen.com> 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
Posted by Rich Bowen <rb...@rcbowen.com>.
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 <rb...@rcbowen.com> 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
>> rbowen@rcbowen.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
>
--
Rich Bowen - rbowen@rcbowen.com
http://rcbowen.com/
@rbowen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: /contribute on project sites
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <rb...@rcbowen.com> 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
> rbowen@rcbowen.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: /contribute on project sites
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Apr 6, 2020 at 8:08 AM Johan Corveleyn <jc...@gmail.com> wrote:
> I thought the below post on dev@community.a.o might be interesting to
> whoever might be working on our website.
>
> Or see it in the archives with possible followups:
> https://lists.apache.org/thread.html/r5b6538a600f7e8ad1a7c31d2b1881882fea190b80930e51a591f500e%40%3Cdev.community.apache.org%3E
>
> (If you're interested, such topics come up once in a while on
> dev@community.a.o, so do subscribe there if you want to find out more
> / want to engage some more with the wider ASF community)
I've created a branch of the website called staging-ng and I've begun
to do some work there. The goal is to give the site a newer more
modern look, support mobile, and make it easier/faster to find key
pieces of information with less reading and fewer clicks required,
while keeping it as easily versioned html/ccs. There isn't much
progress to show yet because I spent most of the time studying other
ASF sites, other F/OSS project sites in general, and then the Press
Release and more recent work/testing for 1.14.x has taken up my time.
But I haven't forgotten.
On principle, I agree with the idea in the above quoted post. I'll
take a look at that list. Thanks for mentioning it and posting it
here.
Cheers,
Nathan
Fwd: /contribute on project sites
Posted by Johan Corveleyn <jc...@gmail.com>.
Hi SVN devs,
I thought the below post on dev@community.a.o might be interesting to
whoever might be working on our website.
Or see it in the archives with possible followups:
https://lists.apache.org/thread.html/r5b6538a600f7e8ad1a7c31d2b1881882fea190b80930e51a591f500e%40%3Cdev.community.apache.org%3E
(If you're interested, such topics come up once in a while on
dev@community.a.o, so do subscribe there if you want to find out more
/ want to engage some more with the wider ASF community)
Just a FYI.
Cheers,
--
Johan
---------- Forwarded message ---------
From: Rich Bowen <rb...@rcbowen.com>
Date: Sat, Apr 4, 2020 at 2:52 PM
Subject: /contribute on project sites
To: <de...@community.apache.org>
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
rbowen@rcbowen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Re: /contribute on project sites
Posted by Alicia Gonzales <it...@gmail.com>.
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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: /contribute on project sites
Posted by Pierre Smits <pi...@apache.org>.
+1
Met vriendelijke groet,
Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Sun, Apr 5, 2020 at 12:24 PM Jacques Le Roux <
jacques.le.roux@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: /contribute on project sites
Posted by Jacques Le Roux <ja...@les7arts.com>.
+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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org