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 <rbo...@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 > 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
