Hello ComDev-ers! I hope you are all well and that your 2019 is looking bright thus far.
I wanted to share my proposal for recognizing non-technical contributions at the ASF. Whilst some of us have spoken about this issue for many years, this discussion formalized during ApacheCon Montreal (September 2018; select excerpts at the end of this message) and moved onto the ASF Members list for review and vetting. We have received both signoff from VP ComDev Sharan Foga, as well as careful consideration and positive feedback from more than a dozen Members. Let's proceed! Proposed Contribution Process for Non-Technical tasks: 1) Contributions must be associated with an existing ASF project or committee. For example: - Creating supporting graphics for ASF Marketing & Publicity - Providing marketing support for an Apache TLP - Onboarding new contributors to an Apache podling community - Developing a new Website for an existing project - Participating in Apache Community Development activities --staffing the ASF booth, coordinating events, etc. - Writing project/process documentation - Helping with ASF Operations activities --legal/accounting support, etc. ...there are more ways folks can contribute. We just need to give them the ability to do so. 2) The TLP/podling/committee involved must have at least one community member (internal; e.g. PMC) to help provide guidance on the task/activity involved, and at least three PMC Members who may be able to nominate the individual for Committership, as per the ASF's established contributor > committer process http://community.apache.org/contributors/index.html . 3) All project/committee participants are encouraged to sign an ASF ICLA in order to have their contributions recognized. 4) Recognition must happen on-list. 5) All PMCs and podlings are encouraged to consider non-code contributions and establish their own sub-processes for determining how to accept, integrate, and recognize non-technical participation. 6) Recommend that a team of advisors for this process operate under ComDev, and for any serious issues to be escalated to the ASF President and the individuals identified in the ASF Code of Conduct who act as ombudspeople for conflict resolution. 7) Recommend that all non-ASF-Member-confidential tasks/Requests for Assistance be posted publicly on https://helpwanted.apache.org/ ...the form makes it easy to do so! The related details on the tasks themselves may be published on a project's JIRA, blog post, mailing list, Webpage, community forum, Slack channel, etc. 8) Projects/committees are encouraged to share their initiatives with ASF Marketing & Publicity <pr...@apache.org> for additional visibility across ASF communication channels. ...as we build the program, I'm sure we'll be able to flesh out more details and areas of activity. And to kick it off, ASF Marketing & Publicity have some graphics/creative tasks that we will be leading as part of a "Central Services sub-group" under our committee. We will be posting details on blogs.apache.org and promoted to the greater community. Those who are creatively inclined and are able to help are welcome to join us. I hope the proposed process will help encourage broader participation. In my review with Sharan, she wrote: > ... this is just the sort of thing I think Comdev could be doing. It is also > something that could focus us a bit better. > > So +1 from me. Thank you in advance for taking this under the ComDev umbrella and helping pave the way for a more inclusive, robust community. Once you're ready to proceed, I'll be happy to forward/socialize the process to the PMCs if needed. Feel free to let me know if you have any questions or how I can otherwise be of help. Thanks, Sally (ASF's first non-technical member!) - - - Vice President Marketing & Publicity Vice President Sponsor Relations The Apache Software Foundation Tel +1 617 921 8656 | s...@apache.org = = = [BACKGROUND/CONTEXT; excepted from my emails to ASF Members] <snip> During ApacheCon, there were many discussions about two things: 1) "diversity". A pattern was clearly emerging: a) diversity of humanity --one's DNA/gender/ethnicity/background/life choices, etc. b) diversity of contribution --promotion, community building, onboarding, outreach, etc. 2) "(more efficient) ways to get non-code stuff done": a) semi-one-off instances --graphics/logos, marketing/media assistance, etc. b) longer-term items --technical writing, documentation, case studies, etc. c) ongoing support --community building, onboarding/guidance, events coordination, etc. As a firm believer in our process/principles of meritocracy, our often don't knowing who you are is a good thing: if you make decent contributions, there’s a chance that you will be able to establish yourself in the Apache community. Your work should speak for itself. However, it can be difficult for some folks to participate if there’s no clear entry path for them to do so. Much of the history behind what's being discussed goes as far back as my initial participation in the ASF (1999), but the issue became pronounced in 2004. Here's what happened: A certain Web Services-oriented company was heavily involved with a few Apache projects. Not only had they submitted a project to the Incubator, they had a handful of very active committers on their payroll. Their products were Apache-dependent and they worked very hard to bring visibility to their team, their contributions, and, of course, their products (driving sales, and all). Their marketing director wanted to get involved with promoting the project itself, but the PMC said "no, go away". Although their hands were tied, they kept trying different approaches, but were continually rebuffed. Eventually that person left and the company tried again, this time using their community manager. There was a little progress (remnants of "after all, can't trust a marketing person"-itis), but there was still considerable frustration. Through the years, I've regularly received requests to help projects with their marketing and promotions beyond the "Foundation"-level support already provided.The request often comes from a corporate that's heavily invested in the project. And, of course, my answer is "sorry, no", aside from the experiment where I joined a podling that had considerable marketing resources prior to coming to the Incubator, and they had assigned an individual specifically to oversee that project's marketing. I joined the pPMC's new (private) press and (public) marketing lists, and was engaged somewhat passively, and was definitely not driving the effort. A year later, the dedicated marketer jumped ship to their competitor and the project has been struggling to manage this on their own. I eventually unsubscribed from their lists after some years. The reality is that this is not a unique situation. Many projects have active users with their own marketing and PR teams who get assigned to help out in any way possible, and more often than not, the end result gives off the impression that CompanyX "owns" or appears to be inappropriately influencing the project, which, in turn, causes Brand Management, Marketing & Publicity, and at times even the ASF Board to intervene. Those who have been on the receiving end know that you don't want me to come after you <g>. PMCs often want to focus on code and community-builing, and rightfully so, considering that they are the two areas that we actively target/hone our resources. Yet our projects often also need additional support in the form of documentation, graphics/Website development, community events management, marketing/PR/AR, and more. This may not be a full-time role within the project, yet is valuable and necessary to be coordinating with several ASF groups (Brand Management, M&P, ComDev, etc.). Plus, very few technologists/developers/software engineer-types are interested/skilled in these areas. <...> *Recognizing Contributors and Contributions.*** Let's get more people to help with the heavy lifting. Reduce resentment due to lack of recognition. Reduce volunteer fatigue and burnout. We need to establish participation guidelines/requirements. Allow others to offer assistance --even if it’s only for a single project to start. To ensure parity and promote collaboration, any contributor interested in supporting any Apache project will need to participate on the respective Central Services’ list(s). Contributors will be encouraged to help each other out and work through issues together. A "no silo-ing" policy will be enforced. Get on the list, prove yourself, get your wings. <...> I wish others could help drive some of these activities because, #LoveApache. </snip> # # # --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
