Researchers have investigated the bug bounty ecosystem from the lens of platforms, programs, and bug hunters. Understanding the perspectives of bug bounty report reviewers, especially those who historically lack a security background and little to no funding for bug hunters, is currently under-studied. In this paper, we primarily investigate the perspective of open-source software (OSS) maintainers who have used huntr, a bug bounty platform that pays bounties to bug hunters who find security bugs in GitHub projects and have had valid vulnerabilities patched as a result. We address this area by conducting three studies: identifying characteristics through a listing survey$(n_{1}=51)$, their ranked importance with Likert-scale survey data$(n_{2}=90)$, and conducting semi-structured interviews to dive deeper into real-world experiences$(n_{3} =17)$. As a result, we categorize 40 identified characteristics into benefits, challenges, helpful features, and wanted features. We find that private disclosure and project visibility are the most important benefits, while hunters focused on money or CVEs and pressure to review are the most challenging to overcome. Surprisingly, lack of communication with bug hunters is the least challenging, and CVE creation support is the second-least helpful feature for OSS maintainers when reviewing bug bounty reports. We present recommendations to make the bug bounty review process more accommodating to open-source maintainers and identify areas for future work.

Scholars have investigated numerous barriers to accessible software development tools and processes for Blind and Low Vision (BLV) developers. However, the research community has yet to study the accessibility of software development meetings, which are known to play a crucial role in software development practice. We conducted semi-structured interviews with 26 BLV software professionals about software development meeting accessibility. We found four key themes related to in-person and remote software development meetings: (1) participants observed that certain meeting activities and software tools used in meetings were inaccessible, (2) participants performed additional labor in order to make meetings accessible, (3) participants avoided disclosing their disability during meetings due to fear of career repercussions, (4) participants suggested technical, social and organizational solutions for accessible meetings, including developing their own solutions. We suggest recommendations and design implications for future accessible software development meetings including technical and policy-driven solutions.