+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
