Versions Compared

Old Version 3

changes.mady.by.user Rich Bowen

Saved on

compared with

New Version Current

changes.mady.by.user Shane Curcuru

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add audience listing

Planning/Brainstorming doc for community.apache.org website.  We have some newfound energy to improve the website, so it can be a truly useful resource to any kind of newcomer to the ASF or our projects.


Guiding Principles

ComDev is advisory. We recommend best practice. We offer advice. We provide resources. We do not enforce our opinions, nor do we have any authority to compel projects to do anything. In the rare case that we deem a project is off the rails in some aspect, our only option is to make a recommendation to the board.

As such, this site constitutes advice  and best practice, while policy  should be on the main apache.org site, or on the site of the specific VP (eg, Legal, Trademarks) who is responsible for that policy. Any time we find ourselves veering into "you must" rather than "you should", we should identify the top-level policy page that already addresses that topic.

QUESTION: what style guide should we use for signposting these kinds of links?  We'll have a lot of different links back and forth with places like /dev; it would be helpful both as writers and for our audience to have a clear stylistic (or wording) way to signify "See the process over there" or "This is policy, if you'd like to know why it's here, see over there"

TODO

  • TODO Purge ancient/outdated content
    • Mentoring - we do not (currently) have a mentoring program
      • Perhaps note that some projects/other areas might have mentoring programs?
      • Delete content around a mentoring program
      • Move stuff that's actually about GSoC under GSoC
    • Remove mentions of 'helpwanted' service (Done)
    • Remove references to speaker program (Unless someone wants to make that actually a thing)
    • Remove references to community.zones.apache.org
      • Find out what that is (is it a VM?) and drop it.
  • Organize best practice docs by audience
    • Beginner
    • Contributor
    • Committer
    • PMC

Top level content should be about:

      •   (Note: it still technically works with the map, but isn't useful, so agreed to decomission)
    • About half of the files at the top-level of the site
      • comdevboardreports.md
      • newsletter (Two editions, back in 2017. Seemed like a good idea at the time, but didn't last.)
      • calendars/ (This content is a duplicate of events.apache.org) (links to it removed; still need to clean content)

Top level content should help lead anyone - newcomers to the ASF, or committers at ASF projects looking for best practices - to the best place to find information about how the ASF operates.

Improve Onboarding

One of the best times to communicate processes is right when the person needs it; so making all onboarding docs and communications clear and consistent is important.  While much of actual onboarding docs are on apache.org, many FAQs may be on community.a.o.  See list of all onboarding touch points: Proposal: Improving Onboarding Experiences

Key navigation links to include - focus on newcomers

  • Overview topics explaining high-level ASF concepts, what ComDev does, and pointing tech questions to ASF projects themselves
  • Define all major audiences for any ComDev content
    • Newcomers, users, beginners - people outside our active communities who might become active
    • Contributors - people active in communities, but not yet contributor
    • Committers
    • PMC members - have a scope of their project(s) but not necessarily the larger ASF
    • Members et al - advanced topics
    • Corporate leaders and managers - topics showcasing how third parties can best organize their work at the ASF (i.e. companies who pay developers/workers to contribute to an ASF project)
  • Outline Best practices (for specific audiences, arranged up the Contributor Ladder)  
  • Some sort of general pointer to projects.a.o or other information reminding newcomers how many separate projects we have
  • Links to other conceptual best practices (these are important on the larger scale)


Q&A

Q: do we have energy to make different versions of contributor ladder? Developers, testers, designers, writers, etc. each have different interests and paths

A: The main contributor ladder (Contributor → Committer → PMC → Foundation-level governance and membership) is the same for all contributors. Having multiple of these seems like it would unnecessarily complicate something simple, and obscure the central message that there is a path to leadership for everyone, regardless of their interests and skills. The definition of governance, in open source is 1) an explanation of who makes the decisions and 2) an explanation of how you get there. That is the sole purpose of the "ladder", and we should not  complicate that by listing all possible flavors.


Q: How do we effectively help projects with their DOAP files

A: There are several ways we could do this, depending on their expertise and interest:

  1. Notify them that their DOAP is missing/inaccurate
  2. Point to resources about how and where to update it.
  3. Generate possible DOAP for them (there are tools for this) and then encourage them to update it to complete accuracy

...