How can we make the PH more friendly for women to contribute?

[acrymble]

This is an open conversation for the whole world. Please feel free to contribute no matter who you are.

The Programming Historian has currently published contributions from 28 authors and has contributions from another 5 in active peer review. Of those 33 authors, only 9 are female (27%).

We do not typically solicit tutorials (though sometimes we do), so I believe this reflects who has self-selected to participate in the project. We have not rejected large numbers of contributions from women. We have in the past attempted to address this problem by tweeting (June 2014) about the gender disparity and encouraging women to come forward as contributors. In that campaign we had six women agree in principle to write tutorials, and none of them ever submitted anything (they were reminded a number of times but eventually that gets awkward and naggy).

My question:

Is there anything we can reasonably do to address the gender disparity of contributing authors? Is there anything about the way the project is structured or the instructions are written (http://programminghistorian.org/contribute) that prevents more equal contribution rates? Please note any changes and suggestions must allow us to maintain the high quality of tutorial that our readers expect.

I am very keen to hear ideas on this matter.

[miriamposner]

Hey Adam, thank you for raising this important question.

So the first gentle corrective I'd suggest is avoiding posing the question as one of inclusiveness versus quality. There is no reason to believe that achieving gender parity would threaten quality; indeed, as you point out, it's a terrific way to strengthen it.

I suspect that one major factor in PH's gender disparity is this: submitting to PH is still largely an act of volunteerism, and any woman with technical skills is probably already volunteering for 12,000 things, plus serving on panels (about gender!) and speaking at workshops, etc., etc. Think about the women we enlisted to submit tutorials with our last call (Jean Bauer, Micki Kaufman, Sharon Howard, etc.) and then think about how much they're already doing. All the women I know with any programming skill are already doing too much.

If you add childcare responsibilities to the mix, sheer lack of time rules out a lot of women's participation. I imagine you've probably noticed that since my daughter was born I haven't been able to be as active as I had been. That's because evenings and weekends are literally off the table for me now, as they are for many parents. In fact, the only reason I'm able to write this now is that my partner and our daughter are briefly out of town.

So that's one thing, and I suspect that this is a major factor. The second is that I've noticed that since we've moved to Github, participation by women, in the form of comments and questions, has declined markedly. Github is an unfamiliar, opaque platform to many people, and women have well-supported reasons for declining to participate in unfamiliar digital platforms.

I don't actually think that we should abandon Github; I think it's a great way to streamline our editorial processes and it's been working well. It's just that, realistically, we should understand that a lot of women are not going to be super-stoked about signing up for another online platform, participation in which may or may not expose them to all of the myriad offensive behaviors women encounter online.

It's not that women aren't interested in learning to program, as evidenced by PyLadies, Rails Girls, etc., etc. It's just that a) women literally don't have time to volunteer for another thing; and b) women have pretty good reasons for not wanting to dip a toe in unfamiliar online communities.

[acrymble]

Thanks for those thoughts Miriam.

I would like to add I certainly agree with your gentle corrective. I was trying to suggest that we aren't interested in the types of suggestions that will compromise quality. Not that contributions from women are of lower quality, because we know that's not the case.

The too busy point is an interesting one because it contradicts the 'you need to have more women' narrative that we see a lot at the moment. What do I do if I can't find them? Or if my seeking is actually just putting added pressure on them that's ultimately counter productive?

I hadn't considered the github problem. Does that suggest an option for a blind review is needed?

[miriamposner]

Maybe think about this in a different way. Why do you want more women involved? Is it so that people won't yell at you? Or is it because you genuinely believe that women's involvement will strengthen the Programming Historian? (I do.) Imagine if a gender disparity in PH was as intolerable as, say, never mentioning the command line. Then we'd do whatever the hell it took to fix it, because how could you have a decent programming publication without ever mentioning the command line?

If this is the case -- if women's participation is critical to the quality of the publication -- then a range of possibilities suggest themselves.

1. Include women in positions of authority and decision-making. (This is why women are exhausted at being asked to serve on "diversity panels" and what-not; there's no actual authority being conferred.) I would start by recruiting another woman to join the editorial board, and, TBH, preferably a woman of color.
2. With every decision, ask, will this increase women's participation? This is exhausting and extraneous if you're just including women so that people won't yell at you, but remember that we're operating here on the assumption that women's participation in PH is as crucial as including mention of the command-line; it is unthinkable to have a quality publication that does not boast equal participation from women.

There are more, but I gotta go pick up my kid at the airport! Just remember: What would you do if someone told you you could never mention the command line on the Programming Historian? What would you be willing to jettison in order to get that ability back? Do we think getting gender parity on PH is as urgently a matter of quality, not appearance?

[ianmilligan1]

:+1: This is a really important question and discussion, both. I like Miriam's suggestions re: the two points above, and agree we should talk more about the submission process and how to make it more welcoming.

[mialondon]

A very brief comment to +1 Miriam's comment that 'All the women I know with any programming skill are already doing too much'.

On the flipside, do you follow up with potential contributors if you haven't heard from them in a while? They might take silence as a lack of enthusiasm for their idea.

Also, 'females' tends to put me off, so it might put off other women too.

[miriamposner]

Hee hee, @mialondon, I have the Ferengizer browser extension installed, which turns every instance of "females" into FEMALES.

[mollydesjardin]

I never realized these aren't solicited -- could be my own lack of reading comprehension at some point along the way. I would like to write a tutorial but also am not sure what you're looking for (and while I program I'm not a historian anymore). So I'm part of the audience you want to reach. Maybe more tweeting or more prominent messages on the website that these are volunteered? Or although I realize this may not be how you're doing it now, but approaching people to see if they know someonr who'd be interested?

[mollydesjardin]

Also, chiming in that I'd like to see "women" used rather than "female."

[scottbot]

Also +1ing Miriam. Shawn, Ian, and I realized too late that we missed some vital things in The Macroscope that we probably wouldn't have missed had our authorship pool been more diverse. We're happy we can partially remedy this online, but wish we didn't have to. (Hence: quality, not appearance).

According to http://programminghistorian.org/project-team, the team already looks fairly diverse - though making it even moreso would be beneficial, I'm sure. [Edit: Was told privately that a white guy doesn't really get to declare a team diverse. Point well-taken. Not commenting on the team's current diversity, then, I still believe Miriam's suggestion of diversifying the pool is a good one.] On top of that, multiple routes to submissions outside of GitHub seems prudent, and maybe an incentive structure beyond what currently exists. If women, PoC, etc. are already overtaxed, what are some ways to create an incentive for them to publish that PH can offer to everyone, but that a more diverse author pool is more likely to want or need? A CV line only goes so far.

• Money
• Time
• Job prospects
• Some sort of exchange
• Some sort of mutual support structure

Does PH have money to pay authors? Can its team offer time support (maybe trade an author for, say, programmer time)? Is there some way for the editorial board to go above and beyond in helping authors secure jobs? Can PH offer a community, an infrastructure, or some sort of training program fostering a more diverse historical programming environment? Perhaps PH can have "branded" workshops that are explicitly targeted to crowds that are least represented in the authorship pool.

Hope whatever you wind up doing is successful. If it is, it'll be a good model to try to emulate elsewhere.

[FCTweedie]

Can I suggest putting out a call for contributions that you'd like to see? Either for new lessons or updates to current lessons (if these are welcome) and targeting groups that you would like to get involved, via communities such as WIGDET. As Miriam said, Ladies who Tech are often already doing a lot but inviting small contributions might be a good starting point. It sends the message that contributions are wanted. If you can ask for small things, rather than a standalone lesson, that would lower the barrier to entry. It would take more coordination, but what about inviting people to write bits of a lesson?

Personally, I'd like to contribute to PH but am not sure where to start and am a little intimidated by both GitHub and the review process (I never feel 'worthy' in this space, and I think am fairly typical of women in this anxiety). I have a couple of lessons that might be appropriate but am not sure if they are. I've written an Omeka workshop but Miriam has covered this; I have NLTK materials but am still not super-confident to release them into the wild. A woman on my team is writing a Gephi lesson - would there be a place for this?

Agree with @scottbot that some sort of reward beyond the ubiquitous 'exposure' would be great. Can PH offer some form of network/ mentoring? Do lessons currently have DOIs? This might help to increase the citation impact.

[mdlincoln]

:+1: to having a list of desiderata as a way of lower the "what does PH really want" barrier - I would love to see that @FCTweedie. Also :+1: to targeted outreach and, as @mialondon suggested, following up with invited contributors who may have not had time earlier.

[acrymble]

Thanks for all of these suggestions and keep them coming.

I used 'female' rather than 'woman' because I was conscious that I was 27 years old before I felt comfortable with the word 'man' to describe myself, and asking 'women' to participate felt to me ageist.

I'll just try to summarise the suggestions so far:

1) Github may be intimidating and may draw in fears of online abuse for some people 2) Open review may likewise put some people off and a closed option may be appropriate to protect those who feel they need it. 3) A more diverse editorial board (though I would suggest that diversity should look to non-North Americans rather than non-white North Americans) 4) More prolific tweeting 5) Clearer website design to make it obvious to people that we are an academic publication that accepts submissions 6) DOIs for lessons (again, taking on the genre of an academic publication more obviously) (related to issue #147) 7) A list of potential topics we'd like to see 8) A value-added in terms of community mentoring / support / skills 9) Following up on women who havn't submitted things they promised to write 10) Make it clearer that we will work with people pre-submission to sculpt lessons. Adjust tone of current text to sound less threatening. 11) Create a tutorial on how to submit with github. 12) Create a tutorial on using git / version control (tied to 11).

From Twitter

13) Making the submission process easier and less time consuming (again, Github is a barrier for those who don't know it).

[drjwbaker]

On 8), and perhaps slight OT, a minority of PH Live (held in London) attendees were male.

[wcaleb]

A couple of points related to the comments about GitHub and our platform.

GitHub Intimidation

To help new authors overcome the barriers to entry onto GitHub, we've taken a couple of steps so far: I've written step-by-step instructions for making a pull request, and I've also listed my email address on the submissions page encouraging anyone with difficulty to contact me in person. I'm curious to know about other specific steps you all think we could take that would further lower the intimidation factor of an unfamiliar system. We've considered making screencasts walking through the steps of submission; would that be helpful?

Submission Workflows

There is no technical reason why we can't accept lesson submissions in different forms. Any one of us who has permission to modify this repository can create an internal pull request with a submission, and then the review process can continue. But it's worth noticing the two potential downsides:

1. In terms of workload, this means that editors would have to input revisions to the lesson themselves, presumably through extended email correspondence with the author.
2. It could potentially confuse users about who the author of a lesson actually is. If I create a pull request for a lesson I didn't write, my avatar shows up and I'm the pull requester, which may actually interfere with a related goal on this thread of making sure that authors get easily visible credit for all the work they do.

All that said, I'm not opposed to having two totally different tracks for submission: the pull request way, and the email way. I think it does create an additional workload cost for our all-volunteer editorial army to have two different pipelines, but if, as @miriamposner says, we really do want to increase participation by women and we're confident this is a clear way to do it, then we should and it will be worth the additional effort.

Comment Boxes

Also want to note that on our old site, we did have comment boxes on each lesson. We could easy add some sort of Disqus comment box back, if we think that would increase participation. Given the risks of online bullying and trolling that @miriamposner notes and that are well-known in comment boxes, I had sort of assumed (perhaps wrongly) that the slight speed bump to commenting created by having to sign up for GitHub was a plus. And it also eliminates a problem we had on the old site, which was people posting comments about things broken with a lesson that then remained visible even once the broken thing was fixed. All that said, just want to put out there for discussion the possibility that comment boxes could be added back.

[wcaleb]

P.S. Maybe one thing we need to do a better job communicating is that using GitHub for the first time is a challenge. That is, we need to stress to women or men who are intimidated by it that it's not them: it's a platform that takes some time to get used to, but that can be conquered by acquiring a specific set of skills. This isn't something that GitHubbers generally do a good job of communicating: they tend to assume that you just "get it" or don't, but we can set an example here by making sure all of our on-site communications about the platform make clear that (a) it is hard, for everyone, and (b) it can be learned. That might at least help to defuse whatever kinds of stereotype threat the platform may (quite understandably) create for groups of people who are underrepresented on GitHub.

[acrymble]

Thanks @wcaleb. As the editors know, github and its user friendliness (or sometimes lack there of) is a common conversation we have in our meetings.

It is free however, and the alternative submission system we looked at cost £4000 per year. We have zero budget for this project, and we're quite proud of that, so there are trade offs, but as Caleb says, it's about making sure those trade offs are as seamless as possible and that they don't disadvantage certain groups.

[ianmilligan1]

As an editor, I'm happy to work with folks who want to submit via e-mail rather than through GitHub. While I use the platform a lot, I remember finding the learning curve tough. The walkthroughs are great, and screencasts I think might help too, but it does take time.

My own thought of how I'd accept e-mail submissions would be to (a) post the pull request on their behalf, putting author name in the title and text prominently; (b) go through the peer review process on the pull request; (c) and then probably get the author to update the lesson file themselves, before re-uploading it to the pull request. I think that's a feasible workload, while hand-making all revisions on behalf of the author probably isn't. Does this sound workable, @wcaleb?

I really like the discussions around "A value-added in terms of community mentoring / support / skills," as that's probably the most feasible thing we can try to develop (PH really has no money, and I think time might be in scarce supply too, at least as something we could promise). More workshops? More events like the Programming Historian-style drop-ins at the American Studies association or the AHA?

[mialondon]

Is there a pre-submission stage where you work with potential authors to help them make sure their proposed topic is the right size, level and tone, as well as fitting into the overall scope of the PH project? Leaping into GitHub might be as intimidating as a social event as it potentially is as a technical process, but most people are used to kicking ideas around on a piratepad or google doc.

Could you organise mentors for potential authors, who could help them shape their piece before posting it publicly? It'd mean re-thinking how credit is allocated (technically and as collabrotors) but I have the sense that's within scope for the wider PH project anyway.

Cheers, Mia

As an editor, I'm happy to work with folks who want to submit via e-mail rather than through GitHub. While I use the platform a lot, I remember finding the learning curve tough. The walkthroughs are great, and screencasts I think might help too, but it does take time. ... I really like the discussions around "A value-added in terms of community mentoring / support / skills," as that's probably the most feasible thing we can try to develop (PH really has no money, and I think time might be in scarce supply too, at least as something we could promise). More workshops? More events like the Programming Historian-style drop-ins at the American Studies association or the AHA?

---

Reply to this email directly or view it on GitHub: https://github.com/programminghistorian/jekyll/issues/152#issuecomment-155067237

[fredgibbs]

I think many of these excellent suggestions about volunteering lesson ideas and pre-submission editorial work we’ve tried to outline on our contribute pages, particularly under the "Authors: Write a lesson" section on the main contribute page, as well as the entire page at: http://programminghistorian.org/new-lesson-workflow

Are these not visible enough? Probably some of this info should be on our homepage.

It would be very helpful to have specific suggestions for how our existing content does not indicate that we will always have a conversation with any author about a potential lesson and that one doesn't “simply" submit a pull request and hope for the best—although one could, as some people have—but usually there is considerable dialog between editors and authors before then. Certainly that’s our process and policy, but perhaps we’re not communicating that effectively.

On Nov 9, 2015, at 7:31 AM, Mia notifications@github.com wrote:

Is there a pre-submission stage where you work with potential authors to help them make sure their proposed topic is the right size, level and tone, as well as fitting into the overall scope of the PH project? Leaping into GitHub might be as intimidating as a social event as it potentially is as a technical process, but most people are used to kicking ideas around on a piratepad or google doc.

Could you organise mentors for potential authors, who could help them shape their piece before posting it publicly? It'd mean re-thinking how credit is allocated (technically and as collabrotors) but I have the sense that's within scope for the wider PH project anyway.

Cheers, Mia

As an editor, I'm happy to work with folks who want to submit via e-mail rather than through GitHub. While I use the platform a lot, I remember finding the learning curve tough. The walkthroughs are great, and screencasts I think might help too, but it does take time. ... I really like the discussions around "A value-added in terms of community mentoring / support / skills," as that's probably the most feasible thing we can try to develop (PH really has no money, and I think time might be in scarce supply too, at least as something we could promise). More workshops? More events like the Programming Historian-style drop-ins at the American Studies association or the AHA?

---

Reply to this email directly or view it on GitHub: https://github.com/programminghistorian/jekyll/issues/152#issuecomment-155067237

— Reply to this email directly or view it on GitHub https://github.com/programminghistorian/jekyll/issues/152#issuecomment-155079137.

[rlskoeser]

Interesting conversation; I appreciate the thoughtful and practical discussion.

I agree with the comments about being too busy with work and childcare and all the many different places I could be contributing things or projects I could be working on. In my particular case, I'm a programmer but not a historian (my scholarly background is in English literature). When I see the calls for contributions to PH, I think that there are probably things I could contribute that would be useful, but I'm not sure which of the many topics I could write on would be most useful or how to make them relevant/appropriate for a historian.

In regards to the submission process, what about a PH tutorial on GitHub that discusses some of the ways people are using it for scholarly work? I wonder if that would help make the submission process not as intimidating, and give people more reasons to join the GitHub community?

[scottbot]

@fredgibbs Even if the documentation were perfectly transparent and visible, the likelihood that someone will take the work to find it if they already feel too intimidated to contribute is probably pretty low. This may need more word-of-mouth outreach, people blogging about their experience authoring, "mentors" (see @mialondon's reply) going out of their way to advertise their role to potential authors, etc.

[fredgibbs]

OK, so now I’m thinking we should maybe rephrase some of the “editing” / “editor” description on the site to be more focused on “mentoring”. I think that’s how most if not all of the current “editors” feel about what they do, anyway. That could seem considerably more welcoming to potential contributors. And I want to emphasize that I don’t mean this to be a superficial change, but one that really sets an example for scholarly collaboration and publishing (which is what I find so compelling about how PH works, even as it has much room for improvement).

To that end (and Scott’s comment), we might also create a page that lists people who are willing to serve as informal mentors or collaborators for lesson writing—obviously easy to do provided that we can find/recruit/enlist least a dozen or so people willing to do it. Maybe some of the generous folks from this thread (or people they know, who might otherwise be unknown to folks at PH)? I bet a sustained Twitter effort would turn up a few volunteers as well. I really think we should do this (using informal mentors who are somewhat at a distance from PH itself). If anyone else thinks this could be a useful, if somewhat experimental, way forward. I think it’s a great model for softening the lesson creation process.

As an aside, I want to say that working on PH can be really frustrating at times for various reasons, but the wonderfulness of open conversations like this that make the whole project better trump any discontent by at least an order of magnitude.

On Nov 9, 2015, at 8:23 AM, Scott Weingart notifications@github.com wrote:

@fredgibbs https://github.com/fredgibbs Even if the documentation were perfectly transparent and visible, the likelihood that someone will take the work to find it if they already feel too intimidated to contribute is probably pretty low. This may need more word-of-mouth outreach, people blogging about their experience authoring, "mentors" as @mialondon https://github.com/mialondon going out of their way to advertise their role to potential authors, etc.

— Reply to this email directly or view it on GitHub https://github.com/programminghistorian/jekyll/issues/152#issuecomment-155094569.

[wcaleb]

Further idea prompted by @scottbot comments: maybe we could use our blog to feature some "Lesson Creation Stories" or testimonials where authors post brief narratives about the process of coming up with a lesson idea, composing it, getting feedback, and going through the submission process. An alternative but related idea: using the blog for author interviews. For example, @jerielizabeth's lesson on Beautiful Soup was one of the main on-ramps for my own learning of Python; if she's willing, I could imagine interviewing her about her work, how she came to write the lesson, how I used it, etc. Sort of an informal back-and-forth that would lift the curtain on the process further.

[wcaleb]

@rlskoeser Thanks for the idea about a GitHub Tutorial lesson; we do have one in the pipeline but your comment reminded me that I need to check on its status!

[shawngraham]

As a general thought/aside - I've incorporated tutorial writing into my teaching of DH - students write a tutorial for a particular tool or approach, making our own mini proghist. We use the programming historian guidelines on writing for github to do it. It's a long term thing, but my thinking is to try to normalize a lot of this stuff so that it becomes 'just a regular thing that historians do'. (the tutorials the students come up with are pitched a lot lower level than some of the work here, things like how to work with sublime text or other text editor -showing that such things exist is often an interesting jumping off point for discussions of what 'doing dh' means, to the neophyte). It's a small thought, but maybe that kind of thing would eventually broaden the pool of contributors. Thank you all for this discussion!

[fredgibbs]

@shawngraham I'd love to talk more about how to get some of that class work onto PH. I think we could really use some of your students' tutorials--in fact, we've had several conversations about the need for a lesson on using a plain text editors for people who are just starting to push their technical skills. We reference text editing a lot in our tutorials, but a reader without any experience is a little stuck.

Also, @tapar001 is about to start re-invigorating the PH blog with a focus on using PH in the classroom. Might you be willing to contribute a post about your experience in the next few months?

[mdlincoln]

Re: the submission process, I wonder if a change in the presentation of the workflow could help.

If you have an idea for a new lesson, or have already written a tutorial that you think could be adapted for the Programming Historian, contact Fred Gibbs to discuss your idea. This initial contact will help you and us decide if what you’re working on is appropriate for our project. Once our editor has given you the go-ahead to pursue your idea, he or she will post the tentative lesson title, and a brief description to the public Lesson Pipeline wiki page. This is a way of planting your flag in the sand, and helps us avoid multiple people concurrently writing the same or very similar lessons.

This may come across like you need to get past a gatekeeper lest you infringe upon someone else's turf. Which is hardly the intended message, I think!

What if the Lesson Pipeline page is the very first thing potential contributors get to look at, so they can get a taste of the range of projects that PH does find appropriate? If the list of desiderata were on that wiki page as well, then it might help people recognize that work they have is very much worth proposing to @fredgibbs.

[ianmilligan1]

I like the idea of a transparent lesson pipeline (maybe with a graphic?) and framing the editors as mentors. Kim Pham and I went through what I hope was a helpful mentoring process this summer with her lesson - you can check out our commit history on the drafts here (https://github.com/kimpham54/proghist-mappingAPI/commits/master) and the ensuing pull request here (https://github.com/programminghistorian/jekyll/pull/149). The catch there was that Kim was one of our summer fellows, so we already were in touch and had a repartee going.

Echoing earlier things: love @rlskoeser's tutorial idea, getting @shawngraham's class stuff in somehow, and making @mialondon's ideas a reality for all our contributors.

[heatherfro]

Two practical comments: 1 the people primarily discussing how to fix this are men. I will leave this (old and sadly relevant) comment here for reference, and urge you all to think about what this means for moving forward (thank you @miriamposner for yr excellent substitution of women <==> command line earlier) http://dhpoco.org/blog/2013/05/10/open-thread-the-digital-humanities-as-a-historical-refuge-from-raceclassgendersexualitydisability/#comment-2104 2 if you want to make GitHub more accessible as a platform why don't you get a woman to write a tutorial on how to use it? here's one that you can probably borrow https://18f.gsa.gov/2015/03/03/how-to-use-github-and-the-terminal-a-guide/

[acrymble]

@heatherfro I'm not sure what to do about the gender difference in contributors to this thread. I've asked anyone and everyone with ideas to contribute and I don't have any control over who choses to participate. I've had many more women retweet links to this discussion than contribute ideas to it. Why is that? This is about as open an opportunity as we can offer given our resources, to discuss these ideas.

---

Update: In case the problem is github accounts, or a lack thereof, I've just tweeted an option of emailing me ideas, which I'll summarise here if and when I receive them.

[acrymble]

Just by way of update, the current list of suggestions:

1) Github may be intimidating and may draw in fears of online abuse for some people 2) Open review may likewise put some people off and a closed option may be appropriate to protect those who feel they need it. 3) A more diverse editorial board 4) More prolific tweeting 5) Clearer website design to make it obvious to people that we are an academic publication that accepts submissions 6) DOIs for lessons (again, taking on the genre of an academic publication more obviously) (related to issue #147) 7) A list of potential topics we'd like to see 8) A value-added in terms of community mentoring / support / skills 9) Following up on women who havn't submitted things they promised to write 10) Make it clearer that we will work with people pre-submission to sculpt lessons. Adjust tone of current text to sound less threatening. 11) Create a tutorial on how to submit with github. 12) Create a tutorial on using git / version control (tied to 11). 13) Create a tutorial on writing technical tutorials 14) Use the blog more to highlight the process of sharing technical ideas. 15) create a network of mentors 16) encourage coauthorship for busy people, which feeds into that mentoring idea

From Twitter

Making the submission process easier and less time consuming (again, Github is a barrier for those who don't know it).

---

I think we can do a lot with that, and we're definitely taking these ideas seriously, so thank you to everyone who has shared thoughts so far. Always happy to hear more.

[heatherfro]

@acrymble You asked why there is a gender imbalance between who is RTing and who is commenting: I suspect that a huge part of the problem here is that many women don't want or have github accounts. Or if they do have one, and aren't active users (like me, who joined gh just to get a username to sit on and decide what to do with it later). At the moment I worry (and i bet other women reading this worry too) about the potential for this to be an echo chamber of dudes discussing how to fix a woman problem. In other words, I don't think enough women who are interested are willing to create an account just to comment, running the risk of getting lost in a deluge of other people potentially talking over them.

So why stay on GH for soliciting ideas? Github being a barrier to entry to submitting is a recurring issue in this discussion, so clearly it is also a barrier to contributing here. Switch platforms, try an open-ended survey with Google Docs or something which has a very low barrier to entry and gives people the option to be anonymous if they want to. If you want to track responses by gender, include it as a mandatory question (but give at least three options: male / female / prefer not to say).

You can always link back to suggestions here, or summarise your findings back here later if you see fit. You're absolutely right to open this discussion as widely as possible -- but i'm not convinced that doing it on github is as open as you want it to be.

[acrymble]

Thanks @heatherfro that's useful feedback. If someone is willing to work with me to produce text for a more open venue (eg, a survey monkey or something), that'd be much appreciated. I'm wary that I got the vocabulary wrong when trying to set up this venue for soliciting feedback.

[heatherfro]

You can email me- I'm happy to help make this a more egalitarian space. Questions that should probably be pushed into this survey, based on reading this discussion:

• Do you have a github account? If so, please share your username
• Did you know that PH solicits submissions?
• Did you know that PH is an academic publication? (Why/why not?)
• Name one (two?) or more topics you would like to see added to the PH offerings

(other ideas welcome....)

[ndalyrose]

I suspect more women haven't commented on this thread because @miriamposner basically nailed it completely right off the bat and as @heatherfro points out the venue poses a barrier to quickly chiming in with your support/comments :). I'm still floundering my way around GitHub so even with something as rudimentary as commenting here I had to ask @benosteen for clarification on what I was seeing. Obvious now it's no more complex than a simple comment thread but GitHub never fails to make me feel mystified as a default.

[ndalyrose]

But just to add, with a wee bub at home I am basically treading water these days and just don't have the time I used to so building/contributing a new course is unfortunately just right out. However, the role of testing and reviewing the content of new courses is perfect for me as its skill development I need to be working on anyway, and also good insight for our internal staff training programme development so I can make room for it within the context of my day job.

[mhbeals]

I read the above (and related twitter conversations) with great interest, though also some concern. There seems to be a general (and I do mean general) conflation of 'nervous potential contributors' and 'women'. Many of the suggestions for facilitating new contributors were wonderful, and should absolutely be implemented, but I do wonder why they are being associated with women rather than just potential but as yet non-contributors. There are some quite sinister conclusions that can be drawn, for example, by the idea that open/closed review is a gender issue. Indeed, I did not find any of the raised issues particularly gendered. Even the discussion of childcare having significant demands on one's time cannot simply be attributed to gender. As a childless academic, I cannot claim this is a good reason for not contributing, despite my gender, while several of my male colleagues can (but are not expected to). I am fully aware that it is currently more likely that a child's primary caregiver will be a woman, but I don't know that further gendering the role is helpful. And, in the end, statistically, 22 male contributors out of a potential pool of 3 billion men is not that different from 9 women out of a pool of 3 billion women.

Anecdotally, the idea that women who can programme are already very busy is true, but if they are more busy than their male counterparts (of which I see no particular evidence) it may be because the recent push for 50-50 ratios has been solved not by encouraging new entrants but by turning to the same well known individuals again and again in a tick-box exercise of gender diversity and to avoid the #allmalepanels hashtag. I do not presume to accuse the anyone here of raising this solely to bend to social pressure, but it is clearly something weighing on people's minds.The recent creation of a Google List of #dh women was, I'm sure, well meaning, but I don't put together panels based on internet lists. It is and always has been about networking connections. Creating networking opportunities to meet talented people is surely a better idea than a Google Doc. If I found out that I had been chosen off a list, that my work wasn't interesting enough or I had publicised it enough to be known about on merit, I would be horrified. Indeed, I was in the midst of writing my much promised tutorial for the Programming Historian when I saw the tweet advertising this conversation and all I could think was: "Dang it. Better not contribute now. I hate being the token woman."

And, for the record, female, in my opinion is the correct adjective, woman the noun. I am a woman and a potential female contributor.

[acrymble]

Thanks @mhbeals. I agree with you and I hope these suggestions will turn into useful changes, not only for women, but for all users.

For the sake of clarity, I initiated this because I can't see anything we're doing that would make the PH an unwelcoming space for women, and I thought the only way to find that out would be to ask. I also asked because I am a person who needs practical solutions to problems. So much of the rhetoric surrounding these conversations uses language I don't understand (what is a 'safe space', and what is 'male privilege'?). As a practical, let's make a change, type of person, I'm trying to ask people to help translate that jargon into something we can implement in our project to make it as welcoming as possible to everyone.

[jerielizabeth]

This has been a really interesting, encouraging, and thought-provoking conversation to follow.

I would like to add an additional vote to the idea of active mentorship for potential contributors. My own tutorial on Beautiful Soup came into being because I had the opportunity to take a programming course with @fredgibbs -- the topic was chosen and the tutorial was refined to the point that I felt confident with it because of our conversations.

That being said, I would be happy to help out and try to serve that role for others!

[thatandromeda]

http://geekfeminism.org/2012/05/21/how-i-got-50-women-speakers-at-my-tech-conference/ <- That's "50%", not 50 the number, in the URL there. tl;dr it's high-touch and involves making specific invitations to specific people who may not be self-selecting because they don't realize they have things to offer (although they do). (And it involves citing specific aspects of their work that you're interested in showcasing, not just "hey you're a woman", as @mhbeals notes.)

I have a tutorial at https://thatandromeda.github.io/courseware/Intro-via-jQuery/ that I have zero time to rework, but you are welcome to fork it if it's handy for you :)

[acrymble]

Thanks @thatandromeda, you raise an interesting point that we see a lot. I don't have any time to work on your pre existing tutorial either. All of this work we do on PH is evenings and weekends on top of full time academic jobs and family obligations. But there are lots of people out there who might be interested in acting as a coauthor to take in that role. Co authorship is routine to the point of a requirement in the sciences precisely because no one has enough time. Yet it's something that doesn't seem to come onto the radar of humanities scholars, and is often even seen with suspicion.

I'd love to see more of our tutorials coming in from just the situation you suggest, with a pre existing idea reworked by a junior scholar receiving the mentorship of the original author and the support of the editorial team.

As I have said before, we have literally zero budget, so we can't do everything, but we have tried to create a platform of learning and sharing. Collaboration is central to that.

[mialondon]

I appreciate the posts so far. A few general thoughts in random order...

I've missed any twitter conversation but I take @mhbeals point re being careful not to link 'nervous contributor' with gender. While some factors (stereotype threat, fear of and/or past experiences being patronised or hassled on social media) might be linked to gender, hopefully most of the suggestions people have given would help increase the diversity of contributors in lots of interesting ways.

Putting 'how to cite this tutorial' text on pages is another way to make it clear that the tutorials are research outputs.

I like the sound of 'Lesson Creation Stories'. It might also be good to hear more about how you decide what to accept and what's not in scope so that suggesting a tutorial feels less like sending an idea off into the ether.

The list of things I want to learn far exceeds the bits of time I have available to get my head around a new language/configuring my environment etc, so (entirely selfishly), I'd be happy to be an informal reviewer. For example, I'd welcome a chance to learn NLTK.

[erinbush]

@acrymble thank you for posing the question and I really appreciate the discussion thus far.

I'll second (third? fourth?) the importance of active mentoring, and I'm fine with the idea of having non-editors do the mentoring. Github is daunting to me for all the reasons @miriamposner mentioned, but I'd be less apprehensive about using it for open peer review having had solid pre-tutorial discussions. I would consider myself a 'nervous contributor' not because I'm a woman, but because I'm a junior scholar and don't self-identify as a "programmer." If Github is the platform of choice, like it or not, it's a programmer's community and daunting to those of us who consider ourselves "outside" of it.

Like others in this thread, I am happy to help in any way that is useful.

[davanstrien]

I assume the lesson on Github in the pipeline is mine. I'm still quite busy at the moment with finishing my dissertation and work but hopefully will get more time to work on this soon. I have been working on a lesson for a series of events @drjwbaker is running so it shouldn't take too long to write something up.

I'm still very happy to have a go at doing the lesson but if people feel that it would be better written from a different perspective I'm happy to let someone else take over.

[patrickmj]

I'm late to this convo, but glad to get here now. Appreciate all the thoughts and progress.

I'd like to pick up something from @FCTweedie that I think is important about being intimidated not just by GitHub, but also by "the review process (I never feel 'worthy' in this space, and I think am fairly typical of women in this anxiety)".

I don't know how many women have been reviewers, rather than article contributors, but I think that is also important information, and an important way of contributing. It counts as CV lines, and helps establish authority, especially for people in junior positions in academia. Being asked to be a reviewer is a clear, public statement of worthiness. It's also a contribution that doesn't carry as much of a time commitment as an article submission, and might get people enough of an intro to GitHub and the PH workflow (which is indeed an additional twist on 'usual' coder GitHub practices) to make them more comfortable submitting their own article.

So, any data on gender and/or identity breakdown of reviewers? Ways to raise those contributions more to the surface to make it easier to justify the time spent reviewing to a T&P committee?

[acrymble]

Reviewers are 11 female, 27 male.

We do post the names of reviewers, so that is definitely more open than in the traditional peer review model. Unfortunately our system is set up to only post the names of reviewers of lessons that get published. If something doesn't make it through (usually because the author stops responding), then that isn't currently captured by our system.

[amandavisconti]

Some ideas for lower effort and/or less intimidating paths to involvement/credit in addition to full authorship/review of tutorials, with the idea that these may also lead to increased authorship:

1. Adding inline commenting on the PH tutorials could would let tutorial-users identify exactly where and with what wording they've gotten stuck or stopped following the tutorial (rather than describing where in a separate GitHub issue, or meaning to come back and try again later but never getting around to it). Credit could be given to both the user pointing out issues, and any user who replies to these comments and submits suggested improvements for the tutorial (a lower stakes way of getting involved with PH?). Showing people how to turn/check for comments using Hypothesis' Via would be one easy way to enable this on a GitHub Pages-hosted site, e.g. https://via.hypothes.is/http://programminghistorian.org/lessons/understanding-regular-expressions
2. Are there any videos (YouTube/Vimeo) of people going through the tutorials (if not, would you be interested in hosting some as people created them)? Anyone who had worked successfully through a tutorial could create these.
3. PH Live looked like a cool idea; has anything similar been done just online? I've been wondering about new ways of using Slack for DH, and was thinking PH could attract new users (and maybe thus new authors) by hosting live sessions on Slack or elsewhere. E.g., "On this date from 5-9pm, these people will be available on the DH Slack [or Twitter, Google Hangouts, etc.] to answer questions you run into while using the PH Regex tutorial." The sessions could start with a livestream of someone going through the steps of the tutorial, which could then be added to a YouTube channel (#2). Highlights or the whole chat could be kept in the repo for future users (maybe adding any FAQs to bottom of the tutorial?).

__ Thanks to everyone for the contributions in this thread—they've been really useful for me in thinking about other communities I work with!

[shawngraham]

@amandavisconti re your point 2 - some of our grad students here are doing that! I just found this out the other day. I'll post links when they're done (I believe their intent is to do this over the course of this academic year).

[tapar001]

I am very late to this conversation, but I wanted to chime in here to thank everyone for their contributions to this thread, and to show support for this important discussion about accessibility and inclusivity on PH, GitHub, and the digital humanities more broadly.

I would love to see a GitHub tutorial. I've used it for PH and for some digital projects that I'm helping students produce at Minnesota, but I still find the site to be intimidating and not very user friendly. A tutorial that deliberately highlights and clarifies some of GitHub's less intuitive features and terminology could be tremendously valuable, especially if it was written in a reflective way that directly addressed some of the problems that have been discussed throughout this thread about how GitHub is not the most accessible platform around. As a person who is invested in the digital humanities but does not consider himself a programmer, and thus has not had much reason in the past to use GitHub, I know that I would personally appreciate a tutorial that does some work to bridge the gap between those of us who are more and less comfortable with GitHub.

As @fredgibbs mentioned, I'll be working to help curate blog posts on PH about using digital humanities in the classroom. I also really like the idea of having posts that reflect on the process of contributing to PH, and I think it'd be worthwhile to think more generally about how the blog might be a space for encouraging a greater range of voices and perspectives.

[acrymble]

@amandavisconti I like the idea of a live virtual PH event. I had never thought of that.