- opensource-wg - mailman.ripe.net

Fwd: Sovereign Tech Fund : FOSDEM, Challenges Round 2
by Vesna Manojlovic 01 Feb '24

01 Feb '24

FYI === Announcing New Investments Sovereign Tech Fund is starting 2024 with a bang and announcing several new open source infrastructure technologies on which the STF is commissioning work. We’re excited to support these maintainers and FOSS communities, and to continue strengthening the foundational software of our shared digital infrastructure. If you’d like to find out about these updates as they happen, you can find the Sovereign Tech Fund on Mastodon, (etc) https://mastodon.social/@sovtechfund Contribute Back Challenges Round 2 Five FOSS teams have been selected for the 2nd round of STF's Contribute Back Challenges! The projects are receiving a total of €858,560 for their work in the three challenge areas : https://www.sovereigntechfund.de/news/contribute-back-challenges-second-rou… - Improving FOSS Developer Tooling: conda-store, Haskell Cabal & Open Web Docs - Securing FOSS Software Production: Rusty SBOMs - FOSS Infrastructure Documentation: p5.js Documentation Organization & Accessibility Events: See you in Brussels! This week, several members of the STF team will be in Brussels. You can catch up with us at CHAOSSCon Europe (Tara) https://chaoss.community/chaosscon-2024-eu/ EU Open Source Policy Summit (Adriana, Fiona, Powen) https://summit.openforumeurope.org/ FOSDEM (Mirko, Tara, and Fiona) https://fosdem.org/2024/ https://b1sp4.r.ag.d.sendibm3.com/mk/mr/sh/1f8JAEjGcfF85y2ImB9lu0WDqg/Q5X0E…

1 0

OpenWrt One: Project Details and Involvement
by Luka Perkov 22 Jan '24

22 Jan '24

Dear RIPE Open Source WG community, I'm pleased to inform you about a new initiative involving OpenWrt, spearheaded by John Crispin. This project, named OpenWrt One, is focused on creating a specialized wireless networking device aimed at open source software enthusiasts. It emphasizes educational aspects, compliance with FOSS licenses, and a rich array of networking features. You can find out more in these threads: https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/042018.html https://lists.openwrt.org/pipermail/openwrt-adm/2024-January/002479.html Additionally, a portion of the sales revenue from this device will directly support the OpenWrt project. For more detailed information and to participate in discussions related to this topic, please consider subscribing to the relevant OpenWrt mailing lists [1]. Take care, Luka [1] https://lists.openwrt.org/mailman/listinfo

1 0

Second draft: Credit policy for open source projects
by Valerie Aurora 22 Jan '24

22 Jan '24

Hi all, Thanks for the useful feedback on the first draft of the credit policy! Thank you especially to Maria, who wrote many useful additions, all of which are now integrated. My plan is to get one more round of comments on this within the OS wg, then do a public call for comments, then make an initial release. Please review the current version, included inline below and in the Google Docs link (suggestions for better co-editing tools welcome). In addition to Maria's contributions, I made one additional change to the document: a proposed credit and license section using Creative Commons Zero 1.0 Universal license: "This credit policy by RIPE NCC Open Source Working Group and lead authors Valerie Aurora, Maria Matějka (project BIRD, CZ.NIC), Martin Winter, and Marcos Sanz is marked with CC0 1.0. If you create a derivative work, we request but do not require that you voluntarily give credit to the above contributors." This is about reducing friction. The CC BY-SA 4.0 license would require crediting every person who ever contributed by name or risk legal problems, which often causes people to decide it is too much trouble to use. CC0 would allow people to use their judgement on who to credit, without worrying about legal requirements. As such, it is in the spirit of the credit policy itself. My personal view is that the kind of person adopting a credit policy will likely give credit voluntarily. Thoughts? https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6… Valerie Credit policy for open source projects - working draft Introduction The problem: people disagree about credit for contributions Our solution: a written policy Scope of a credit policy Credit for this policy Real-world examples Policy structure Preamble options We welcome a broad range of contributions from as many contributors as possible We welcome contributions that do not need much work We accept outside contributions rarely We prioritize speed of development Only bug fixes welcome My personal project subject to my personal whims Our corporate project not open to outside contributions Our research project not open to outside contributions [YOUR PREAMBLE HERE] Credit assignment options Correcting mistakes in credit Reporting problems with credit Introduction The purpose of this document is to develop an example credit policy: a written description of how an open source software project gives credit for contributions. This project was created and led by many members of the RIPE NCC Open Source Working Group: https://www.ripe.net/participate/ripe/wg/active-wg/os The problem: people disagree about credit for contributions Open source software projects receive a wide variety of contributions from many different people and organizations. Each contributor has their own assumptions and expectations for what kind of credit contributions should receive. When there is a mismatch between the credit a contributor expects to get and what they actually get, both the project and the people around it suffer. This is an especially important problem for open source software because the main motivation for contributing is often recognition and credit; when people don't receive what they expect, they are less likely to contribute in the future. This also applies for upstreaming local changes. Even though the main motivation may seem to be some reduction of future maintenance costs, all the parties benefit from proper crediting, e.g. when some changes in the contributed code are proposed in future and consulting with the original authors is handy. Two concrete examples: How I got robbed of my first kernel contribution – Ariel Miculas Someone sends in a contribution that needs a little more work. The other contributors are too overworked to review the contribution. Some time later, another person fixes the same problem without ever seeing the first contribution. The first person says, "Hey, why did you rewrite my work without giving me credit?" Our solution: a written policy Our proposed solution to this problem is for each project to write down and publish a formal credit policy (or contribution policy, or anti-plagiarism policy - whatever name seems best). This policy describes what kind of credit and acknowledgement contributors can expect. It also serves as a guide for decision-making for project leaders when they run into more complex problems associated with credit. The end result is that contributors are more likely to contribute to projects with matching credit policies, and project leaders spend less time arguing with contributors or trying to decide how to handle edge cases. The example policy we are writing in this document includes a variety of different ways to assign credit, depending on the project's goals and priorities. Projects can copy parts of the example policy and edit as necessary, or create their own policies from scratch. Scope of a credit policy The policy should cover all types of contribution: documentation, code, tutorials, event organization, testing, design , etc. It should focus primarily on cases in which multiple people or organizations are collaborating on a contribution, when people disagree about who gets credit, and other situations in which credit is less clear. It does not attempt to resolve any legal issues around IP or copyright; that is the domain of contributor agreements, licenses, and other documents. Credit for this policy If you contributed to this policy, please add your name here. We will decide how to credit the contributors as we develop this policy. Valerie Aurora Maria Matějka (project BIRD, CZ.NIC) Martin Winter Marcos Sanz Fair warning: the most successful policies are often the ones with no attribution since people often reject them when their provenance is called out. Ironic, huh? Real-world examples Here are few examples of situations that a credit policy should address: Someone sends a first draft (of a document, code, HTML, etc.). A second person makes significant edits to it. Someone sends a first draft. Another person comments with ideas leading the original sender to incorporate them in the second draft. Someone sends a first draft. Another person entirely rewrites it from scratch. Someone sends a contribution. The contribution does not improve the project. Someone sends a contribution but does not complete the "sign-off" or other process step that the project requires. The first reminder goes unanswered for several days. Someone sends a first draft. It fixes a real problem but in a way that is unacceptable for inclusion. They do not respond or are unwilling to make the necessary changes for inclusion. Someone sends a contribution but no one else in the project notices. Later another person makes a similar contribution and gets credit for it. Someone sends a contribution which is actually valuable to the project but directly conflicts with other project plans and aligning it means to actually rewrite the contribution completely. Someone sends a somewhat useless contribution. When you look at their contribution history, you see them sending a lot of useless contributions to other projects. Someone sends a contribution that seems suspicious. When you look at their contribution history, they seem to have rewritten a lot of other people's contributions. Someone sends a lot of tiny separate trivial contributions. They aren't actually making much difference to the project, but if you accept them all it will look like they should have credit for half the project. Someone sends a contribution. For whatever reason, the contribution does not actually seem to be motivated by a desire to improve the project. Someone sends a contribution but a project leader hates the style. Someone sends a contribution and it seems kind of mean-spirited. Someone sends a complaint which gets ignored or rejected. Later, the maintainers find themselves fixing the subject of the complaint anyway. Policy structure The policy should consist of the following parts: Preamble describing the overall goals and philosophy of the project's credit policy High-level description of how credit is assigned for contributions List of specific situations with step-by-step instructions on what to do in each one How to contact the project if someone thinks that credit has not been given correctly Instructions for people implementing the credit policy, including what to do in difficult situations The last part does not need to be published but can be. Preamble options The preamble describes the overall philosophy of your project towards contributions: what kind of contributions you want to encourage, what kind of contributors you want participating, what your priorities are when it comes to different aspects of quality or productiveness. Your preamble should discourage the kind of contributions you don't want and encourage the kind of contributions you do want. Note: The more contributions you want to encourage, the more documentation you actually need. It’s hard to welcome a broad range of contributions with lack of programmer’s documentation and proper open future planning, including upfront disclosure of (or hosting public discussions on) architectural decisions, to guide the contributors even before they actually start working. Here are some possible preambles that prioritize different goals. We welcome a broad range of contributions from as many contributors as possible We encourage contributions from as many contributors as possible, and strive to make contributing easy and rewarding. We prefer to guide original contributors through the process of making necessary changes to any contributions, and reward mentoring and review. When a contribution is the combined effort of several people, we prefer to give primary credit to newer contributors. We give credit generously for all of the work that goes into making this project a success, including testing, review, debugging, mentoring, operations, documentation, and similar work. We welcome contributions that do not need much work We encourage contributions but our existing contributors have limited time to mentor or guide new contributors. When a contribution needs changes, existing contributors will usually make any necessary changes themselves rather than working with the original contributor to make the changes. However, we strive to give primary credit to the original contributor whenever possible. We especially encourage contributions that make it easier for new contributors to become productive without direct mentoring, such as documentation, tutorials, refactoring, tests, and similar. We accept outside contributions rarely Our priority is quality of contributions and architectural cohesion. We prefer contributions from existing contributors who are already familiar with our processes and standards, and are carrying out the architectural vision of our leaders. We do not mentor or guide new contributors. When existing contributors rewrite, reuse, or are inspired by contributions from new contributors, it is up to the existing contributor to decide how or if to credit the original author. We prioritize speed of development Our priority is speed of development. We reward contributors who send working contributions quickly. We prefer to give credit to the person who sends the first acceptable form of a contribution rather than the original contributor. Only bug fixes welcome [YOUR DRAFT HERE] My personal project subject to my personal whims [YOUR DRAFT HERE] Our corporate project not open to outside contributions [YOUR DRAFT HERE] Our research project not open to outside contributions [YOUR DRAFT HERE] [YOUR PREAMBLE HERE] Credit assignment options Here are a selection of possible rules for assigning credit. You should choose the ones that encourage the behavior you describe in your philosophy. For example, if you want to encourage new contributors, choose rules that give credit more generously to new contributors than existing ones. If you want existing contributors to have strong control over the project, choose rules that give credit more generously to people who edit or rewrite contributions. Note: don’t get too wrapped up in who “really wrote a contribution.” Most contributions are a collaborative effort by multiple people and it would be impossible to give credit to every single person who made a one line contribution to your project possible. Instead, focus on what behaviors you want to reward and which ones you want to discourage, and be creative about how you do that. If a contribution includes substantial work from multiple authors, we will give primary credit to the least experienced contributor. If we need to rewrite a contribution, we will give primary credit to the author of the first version and secondary credit to the person rewriting it. If we need to rewrite a contribution, we will give primary credit to the person rewriting it and secondary credit to the author of the first version. If we need to rewrite a contribution, we will work with the original author to make the necessary changes for as long as they respond in good faith and in a timely manner. In any case, the original author will get primary credit. The project leaders are the sole authority on who gets credit and will assign it to no one, to themselves, or to others as they see fit. All people and companies involved in the contribution get credits equally. If multiple contributors submit similar work, the accepted author gets primary credit and every other contributor, whose work was thus rejected, gets secondary credit. [YOUR SUGGESTION HERE] Please make it easy for us to accept and credit your contribution! Here are the steps to take to get the most credit for your work: [CHOOSE APPLICABLE] Include “Signed-off-by: [YOUR NAME]” Put your name into the AUTHORS file Agree to the CLA Follow the instructions in CONTRIBUTING Respond to requests for changes within N days Cooperate in good faith with our requests for changes If you do not want to make changes, please tell us as soon as possible [YOUR SUGGESTION HERE] If for some reasons you can’t or won’t make necessary changes to your contribution, we will [CHOOSE ONE OR MORE AND EDIT TO FIT] Reject your contribution and take no further action. Incorporate your original contribution as is, then make a second change with any edits. Incorporate your contribution along with any necessary edits with primary credit to the newest contributor, with a link in the change message to your original contribution on our mailing list or other archive of original contributions (e.g. a directory in the source code, a section of the wiki, etc.). If you did not [sign off, agree to the CLA, other necessary process step], we will rewrite from scratch and include a link to the original contribution in the change message. How we give credit: For commits to a repository, the primary author is the commit author. For reviews, editing, testing, debugging, or reporting directly related to a specific contribution, we add a line in the change message such as “Reviewed-by” or “Edited-by”. For contributions that are not specific to an individual change, such as hosting, DevOps, DevRel, issue curation, etc, we will add your name to [LIST AND LOCATION OF PUBLICATION]. To be added to this list, please [INSTRUCTIONS]. [Suggestion: include an option for extremely minor contributions.] [YOUR SUGGESTION HERE] We reserve the right to not grant credit when it seems detrimental to our project. For example, if someone requests credit to a name that is obscene or harmful, if they are spamming multiple projects with minor contributions, or if interacting with a contributor is demoralizing to other contributors. Correcting mistakes in credit Sometimes we make a mistake in how we give credit. In this project: [CHOOSE FROM FOLLOWING] Once credit has been given, we will not go back and correct it. We will correct mistakes in credit attribution for up to [TIME PERIOD] after credit has been given. We will correct mistakes in credit at any point. [YOUR SUGGESTIONS HERE] Reporting problems with credit If someone has not given credit correctly, please contact [CONTACT INFORMATION - COULD BE CODE OF CONDUCT COMMITTEE] and include any relevant information. [NAMES] will review your report and take any action they deem appropriate, including but not limited to updating the credit information, warning the person who did not follow the credit policy, no longer accepting their contributions, or forwarding the complaint to the community code of conduct committee. Credit and license This credit policy by RIPE NCC Open Source Working Group and lead authors Valerie Aurora, Maria Matějka (project BIRD, CZ.NIC), Martin Winter, and Marcos Sanz is marked with CC0 1.0. If you create a derivative work, we request but do not require that you voluntarily give credit to the above contributors.

2 2

Minutes of RIPE87 Open Source wg meeting
by Marcos Sanz 17 Jan '24

17 Jan '24

Dear all, The minutes of our last working group meeting are now online https://www.ripe.net/participate/ripe/wg/active-wg/os/minutes/open-source-wo rking-group-minutes-ripe-87 Thanks to Razvan Oprea for the note taking. Any errors or omissions on me to blame! Yours, Marcos

1 0

Welcome the new open source wg co-chair!
by Marcos Sanz 22 Dec '23

22 Dec '23

Dear working group, dear RIPE community, first of all, we'd like to say a big thank you to all three candidates. Based on the feedback for all the candidates, the expressions of support and the discussion afterwards on which voices to consider, we have decided on Sasha Romijn to join us as the 3rd working group chair. We know that some new individuals on this list will not agree, but we do believe we have decided based on what is best for the WG. After the announcement end of last week that we were prioritizing expressions of support from long-standing members, we have not heard any reason why this would be a bad procedure and we have got a lot of on-list and off-list feedback supporting it. Having said that, we will bring up the chair selection topic at the next RIPE meeting and welcome everyone to join us for that discussion. The last three weeks have showed that we might be needing clearer guidelines in the process. We would like to address this with the group in time before the next election in fall 2024. Now, please welcome to Sasha as a Co-Chair for the Open Source WG! Regards, Martin Winter & Marcos Sanz Open Source WG Chairs

7 6

Re: [opensource-wg] Call for support of co-chair candidates
by Ines Skelac 21 Dec '23

21 Dec '23

Dear Martin, Thank you for your quick response. It's important for me to clarify my position regarding the RIPE chair selection process, and equally important to receive responses to my points that remain unanswered. Firstly, with respect to Luka Perkov, our interactions have been within a professional context. It is through these professional interactions that I have been introduced to RIPE and its various activities on multiple occasions. Regarding the other candidates, I assure you that my vote was cast following a thorough and informed examination of their profiles and contributions. During my research, I observed an instance where an individual associated with RIPE used their official ripe.net email address to cast a vote. The deliberate choice of using a RIPE email implies a certain awareness of the influence it carries. This early vote, seemingly endorsed officially, subtly suggests a process that might appear, to the cautious observer, as conveniently arranged. When combined with the evolving narrative of whose votes count and whose don’t — as if the rules are being written and rewritten in real-time — it certainly raises eyebrows about the true consistency and impartiality of this process. In light of our commitment to transparency, I'm curious – will this vote be counted, or are we continuing to adapt the rules to fit the moment? In our dialogues, a recurrent issue is the cycle of new questions that emerge following my responses, often sidestepping the depth of the answers I've already provided. This pattern of continuously shifting focus hinders our ability to delve deeply and transparently into the core issues. Moreover, when discussions reach a significant point, they are frequently concluded with statements and conclusions like "you did not convince me," which serve more as conversation enders than as constructive contributions. Given this, will my points raised in the previous email be thoroughly addressed? The absence of a detailed response will be quite telling and, in itself, a significant answer, especially in light of the critical issues I have brought forward. To reiterate, my decision to participate in the voting was informed by a thorough understanding of RIPE, the Open Source Working Group, and the qualifications of all the candidates. I trust this message clarifies my position well. Considering the observations and discussions above, I am looking forward to your responses to these points, as well as to the unresolved topics I mentioned in my previous email. Clear answers to these concerns are to allow everyone within the community to contribute more effectively. Warm regards, Ines uto, 19. pro 2023. u 22:06 Martin Winter <mwinter(a)netdef.org> napisao je: > Ines, > > thanks for the introduction. However, I'm less concerned and about > your professional background and was actually asking on how you found > about the Open Source WG and the election going on. You mentioned that > you know Luka and trust him, but do you know the other candidates? I'm > concerned on people voting who did not take the time to look at all > the candidates and just pick a local friend. > > So again, if you think we should count your particular vote, then > please explain: > - How did you learn about the chair selection process? After all, the > email for the selection process was sent before you joined. > - How did you decide that your choice is better than the other > choices? After all you are new to this group and seem to be still > confused about it. (I take this from the mention of the number of > emails on the list. We mainly work on the meeting, so while it would > be nice to have a more active list, our main charter isn't the list. > Go and check out the RIPE websites for our mission on this (and other) > WG > > And if you would have attended the past RIPE or listened to the > recording, then you would probably better understand the selection > process. And yes, things were not done perfectly and I currently plan > to bring this up at the next WG meeting at the RIPE in spring 2024. > Attend the meeting and join in on the discussion on how to make the > selection better. > Also keep in mind, this is a chail selection process. And myself and > Marco (the existing chairs) did not publicly mention as I didn't want > to set an example for others to follow or influence. And yes, my first > choice didn't make it either. > > So far you did nothing to convince me - more to the opposite that I > have the feeling you try to avoid the answers to the questions. But > that's fair. And I don't expect you to open up to everyone, but you > try to make a point that your vote should count and I still haven't > heard an argument about why. > > But please stick around and join us at future RIPE meetings. You may > learn how we may not have fixed rules, but we decide mostly on what is > best for the community. (And you could learn why this helps) > > Regards, > Martin Winter > > > On Tue, Dec 19, 2023 at 2:17 PM Ines Skelac <ines.skelac(a)ffrz.hr> wrote: > > > > Dear Martin, > > > > Thank you for extending a welcome to me and for engaging in this > important dialogue. I am grateful for the opportunity to share my > perspective and to deepen my involvement with the RIPE community. > > > > In your email, you highlighted the importance of being a well-informed > and active member of the community, particularly in the context of voting > for leadership positions. However, the growing inconsistency surrounding > the nature of this process — whether it was intended as a public call for > candidate support, a forum for expressing opinions, or an element of a > specific selection procedure — is of considerable concern. This lack of > clarity, which appears to be more than coincidental, has left myself, and > possibly others, in a state of doubt regarding the appropriate way to > respond and participate. My actions were based on the directives issued by > the current chairs, yet I now find myself questioning if there might be a > deeper, possibly unspoken, agenda underpinning these communications. While > it perhaps truly is coincidentally inconvenient that such ambiguities were > not adequately addressed prior to "unusual traffic in the list”, I would > greatly appreciate your guidance in shedding light on the true purpose and > framework of this initiative. > > > > In my quest to navigate through this entanglement, I delved into the > historical records of our mailing list. My investigation revealed a notably > sparse flow of communication, with only about 20 emails exchanged annually > on average. Given that we are now approaching the year's end, I am > expecting that someone might at some point propose a thoughtful reduction > in email traffic for these remaining days of December. This strategy > potentially could preserve the customary communication patterns, ensuring a > well-balanced and smooth transition into the upcoming year, and potentially > revitalizing the usual dialogue dynamics within the list. > > > > Despite these well designed roadblocks, I would like to offer some > insights into my involvement and interest in the RIPE community, which will > allow you to make informed decisions and not uninformed opinions. > > > > I agree that knowing who we collaborate with is key for effective > teamwork. Acknowledging your concerns, I appreciate the chance to introduce > myself. Surely you have noticed that I've used my official email for group > subscription to affirm my genuine interest and identity, underscoring my > commitment to maintaining the integrity and trustworthiness of our voting > process. > > > > As a philosopher and computational linguist with experience in training > language models and the ethics of big data, I believe I can offer insights > and expertise to the RIPE community. My introduction to RIPE was through a > recommendation by Luka Perkov, a long-time collaborator, and a respected > member of the open source community. Over the past year, my research group > has extensively utilized statistical data, which has been very useful in > our work. At the University of Zagreb as well as at Entimem Ltd, we have > specialized in deep learning analysis of religious texts of various > religions, and RIPE's data has been helpful in measuring activities, aiding > our project proposals and research. > > > > As I have now introduced myself in this e-mail as requested, I am now > very interested to learn more about other members in the same way, namely > those whose opinions are given weight in these discussions and decisions so > that I am at least given an opportunity to engage in the conversation. This > would not only foster a sense of safety and inclusion but also align with > the RIPE’s Code of Conduct, where it is stated that one of the main goals > of the RIPE community is “to help everyone feel safe and included. Many > people will be new to our community. Some may have had negative experiences > in other communities. We want to set a clear expectation that harassment > and related behaviours are not tolerated here. If people do have an > unpleasant experience, they will know that this is neither the norm nor > acceptable to us as a community.” > > > > In closing, I would appreciate any information on how we collaborate and > meet outside of the RIPE meetings, so I can efficiently plan my > involvement. Additionally, if there are any resources, guidelines, or > specific contacts that could help me get started and blend more smoothly > into the team, I would be most grateful for that information. What I have > seen so far is very intriguing and I am very interested to understand the > dynamics of the community. > > > > > > Warm regards, > > > > Ines > > > > > > > > > > > > pon, 18. pro 2023. u 11:25 Martin Winter <mwinter(a)netdef.org> napisao > je: > >> > >> Ines. > >> > >> First of all welcome. And yes, you are one of the impacted persons as > >> well who just joined the list after the RIPE meeting, not attended any > >> recent RIPEs and were still informed well enough to immediatly vote > >> after joining the list. > >> > >> On Sun, Dec 17, 2023 at 9:14 AM Ines Skelac <ines.skelac(a)ffrz.hr> > wrote: > >> > > >> > Dear RIPE Community, > >> > > >> > I am writing to express my disappointment and concern regarding the > recent decision-making process for the open co-chair position in the RIPE > community. As a new member of this esteemed group, I find the approach > taken to be both disheartening and alarming. > >> > >> Is it really alarming that we don't allow votes from people who were > >> not part of the community when the voting started? In all democracies > >> I know, > >> you have to be registered/present some time before the voting starts. > >> If you would be part of the RIPE community for a bit longer then you > >> would be aware that usually the voting would be at the meeting itself. > >> We decided at the last minute to give people a bit more time after > >> they heard each of them introducing themself at the meeting and give > >> them 2 weeks to make up their minds. Maybe we should have been clear > >> that later joins are not eligible to vote, but then you wouldn't have > >> seen or heard that anyway as you were not yet part of the community. > >> > >> So instead of making wild accusations that this is alarming, please > >> take yourself as an example and explain why YOUR vote should count. > >> Explain how you know about the voting and how you heard about ALL of > >> the candidates and about your past experience with RIPE (which got you > >> a bit familiar with the community, our goal of the WG) - which I > >> assume you all know to be able to pick the best candidate. > >> Please be aware, we didn't look for the most popular person or the one > >> with the most followers or the best Open Source background. We were > >> looking for the best choice for a WG chair. How this is defined might > >> be viewed differently by each person. > >> > >> If you can explain this, then we might be happy to reconsider counting > >> your vote. > >> So far, the only ones complaining are the ones who signed up days > >> after the meeting and voted immediately. > >> > >> > The decision to disqualify votes from new members who may not have > had the opportunity to attend a RIPE meeting or were not subscribed to the > mailing list by a specific date seems not only unfair but also > counterproductive. This approach overlooks the potential contributions of > new members and creates an unwelcoming environment. It also appears to be > grounded in logical fallacies, such as the 'post hoc ergo propter hoc' > fallacy, which undermines the rationality of this decision. > >> > >> Please be aware that you can attend RIPE for free from remote. No > >> travel required. No money required. This is a very low entry level. > >> And no, this does not produce a unwelcoming environment, but protects > >> the working group to be not potentially controlled by some outside > >> force. > >> By your definition, welcoming would mean that I can create a bot to > >> create votes and you expect them to be counted. Or I can go and ask > >> all my friends to join and vote in exchange for a beer. This has > >> nothing to do with welcoming, but all about protecting the integrity > >> of the vote. > >> > >> I welcome you to join the next RIPE meeting and bring up this in > >> person to discuss with the whole group. > >> > >> Regards, > >> Martin Winter > >> Open Source WG Chair > >> > >> > > >> > Moreover, such a stance is unacademic and unethical. It disregards > the principles of open dialogue and diversity of perspectives, which are > crucial in any intellectual community. Disqualifying members without > substantial evidence and not acknowledging the value of fresh perspectives > can severely damage the integrity and reputation of the RIPE community. > >> > > >> > As a new member eager to contribute, this experience is not only > disheartening but also raises concerns about the future direction of the > community. I urge the leadership to reconsider this approach and adopt more > inclusive and equitable practices. The strength of a community lies in its > diversity and openness to all voices, including those of its newest members. > >> > > >> > I hope that my concerns will be taken seriously and that we can work > together towards a more inclusive and respectful RIPE community. > >> > > >> > > >> > > >> > Sincerely, > >> > > >> > Ines Skelac, PhD, Assistant Professor > >> > > >> > Vice-dean for Science, International Cooperation, Management and > Quality Assurance > >> > > >> > University of Zagreb, Faculty of Philosophy and Religious Studies > >> > > >> > > >> > > >> > > >> > sub, 16. pro 2023. u 23:45 Ondřej Surý <ondrej(a)dns.rocks> napisao je: > >> >> > >> >> Oh, I didn’t want to imply any intentional wrongdoing. I simply > suggested that stepping down in such situation might be the best way to > acknowledge the less than ideal situation and prevent the possible argument > that might drag for a long time. > >> >> > >> >> Ondrej > >> >> > >> >> On Sat, Dec 16, 2023, at 23:22, Martin Winter wrote: > >> >> > >> >> Ondrej, > >> >> > >> >> On Sat, Dec 16, 2023 at 9:31 PM Ondřej Surý <ondrej(a)dns.rocks> > wrote: > >> >> > The way I read the decision from the chair, they strive to have > the voting process work for the existing community. If suddenly there’s a > surge of people who were never active in this community subscribing to the > mailing list and voting for any of the candidates, I would consider this be > a kind of hostile takeover. > >> >> > > >> >> > Honestly, I think the only fair way out of this would be if the > candidate who received the surge of votes from people outside of this > community stepped down. A co-chair elected with votes from people who never > participated in the RIPE community would not be accepted by this community > and it would be divisive and toxic to the future work. > >> >> > >> >> I don't like to go this far. We (as the chairs) have no proof or > >> >> indication that any of the candidates actively tried to manipulate > the > >> >> voting. However, some candidates might be more popular in their own > >> >> social circles and may have mentioned that they are candidates. And I > >> >> think that's all good and fair. > >> >> I can't blame the candidates for this or for the fact if someone then > >> >> just signed up to vote for him. I have no indication that he/she > >> >> motivated them to do this. > >> >> As such, I assume all candidates are innocent and did not try to > >> >> manipulate the voting. > >> >> > >> >> Regards, > >> >> Martin Winter > >> >> Open Source WG Chair > >> >> > >> >> > >> >> -- > >> >> Ondřej Surý (He/Him) > >> >> ondrej(a)sury.org > >> >> > >> >> _______________________________________________ > >> >> opensource-wg mailing list > >> >> opensource-wg(a)ripe.net > >> >> https://lists.ripe.net/mailman/listinfo/opensource-wg > >> >> > >> >> To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/opensource-wg > >> > > >> > > >> > > >> > _______________________________________________ > >> > opensource-wg mailing list > >> > opensource-wg(a)ripe.net > >> > https://lists.ripe.net/mailman/listinfo/opensource-wg > >> > > >> > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/opensource-wg >

4 3

Call for contributions: Example credit policy
by Valerie Aurora 20 Dec '23

20 Dec '23

Hi all, Thanks for everyone's enthusiasm at the RIPE session about the open source project credit policy! While recovering from COVID I managed to put together a starting draft that included all of the suggestions I could remember. Please edit the draft, via comments, suggestions, or direct edits: https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6… Please don't share this link outside this group but do feel free to share copies or solicit outside feedback. A copy of the current text is at the end of this email. Thank you in particular to Maria Matějka, Martin Winter, and Marcos Sanz for many excellent points and solutions. Valerie Link to video and slides: https://ripe87.ripe.net/programme/meeting-plan/os-wg/ Introduction The purpose of this document is to develop an example credit policy: a written description of how an open source software project gives credit for contributions. The problem: people disagree about credit for contributions Open source software projects receive a wide variety of contributions from many different people and organizations. Each contributor has their own assumptions and expectations for what kind of credit contributions should receive. When there is a mismatch between the credit a contributor expects to get and what they actually get, the project suffers. This is an especially important problem for open source software because the main motivation for contributing is often recognition and credit; when people don't receive what they expect, they are less likely to contribute in the future. Two concrete examples: How I got robbed of my first kernel contribution – Ariel Miculas Someone sends in a contribution that needs a little more work. The other contributors are too overworked to review the contribution. Some time later, another person fixes the same problem without ever seeing the first contribution. The first person says, "Hey, why did you rewrite my work without giving me credit?" Our solution: a written policy Our proposed solution to this problem is for each project to write down and publish a formal credit policy (or contribution policy, or anti-plagiarism policy - whatever name seems best). This policy describes what kind of credit and acknowledgement contributors can expect. It also serves as a guide for decision-making for project leaders when they run into more complex problems associated with credit. The end result is that contributors are more likely to contribute to projects with matching credit policies, and project leaders spend less time arguing with contributors or trying to decide how to handle edge cases. The example policy we are writing in this document includes a variety of different ways to assign credit, depending on the project's goals and priorities. Projects can copy parts of the example policy and edit as necessary, or create their own policies from scratch. Scope of a credit policy The policy should cover all types of contribution: documentation, code, tutorials, event organization, testing, design , etc. It should focus primarily on cases in which multiple people or organizations are collaborating on a contribution, when people disagree about who gets credit, and other situations in which credit is less clear. It does not attempt to resolve any legal issues around IP or copyright; that is the domain of contributor agreements, licenses, and other documents. Credit for this policy If you contributed to this policy, please add your name here. We will decide how to credit the contributors as we develop this policy. Valerie Aurora Maria Matějka Martin Winter Marcos Sanz Fair warning: the most successful policies are often the ones with no attribution since people often reject them when their provenance is called out. Ironic, huh? Real-world examples Here are few examples of situations that a credit policy should address: Someone sends a first draft (of a document, code, HTML, etc.). A second person makes significant edits to it. Someone sends a first draft. Another person entirely rewrites it from scratch. Someone sends a contribution. The contribution does not improve the project. Someone sends a contribution but does not complete the "sign-off" or other process step that the project requires. The first reminder goes unanswered for several days. Someone sends a first draft. It fixes a real problem but in a way that is unacceptable for inclusion. They do not respond or are unwilling to make the necessary changes for inclusion. Someone sends a contribution but no one else in the project notices. Later another person makes a similar contribution and gets credit for it. Someone sends a somewhat useless contribution. When you look at their contribution history, you see them sending a lot of useless contributions to other projects. Someone sends a contribution that seems suspicious. When you look at their contribution history, they seem to have rewritten a lot of other people's contributions. Someone sends a lot of tiny separate trivial contributions. They aren't actually making much difference to the project, but if you accept them all it will look like they should have credit for half the project. Someone sends a contribution. For whatever reason, the contribution does not actually seem to be motivated by a desire to improve the project. Someone sends a contribution but a project leader hates the style. Someone sends a contribution and it seems kind of mean-spirited. Policy structure The policy should consist of the following parts: Preamble describing the overall goals and philosophy of the project's credit policy High-level description of how credit is assigned for contributions List of specific situations with step-by-step instructions on what to do in each one How to contact the project if someone thinks that credit has not been given correctly Instructions for people implementing the credit policy, including what to do in difficult situations The last part does not need to be published but can be. Preamble options The preamble describes the overall philosophy of your project towards contributions: what kind of contributions you want to encourage, what kind of contributors you want participating, what your priorities are when it comes to different aspects of quality or productiveness. Your preamble should discourage the kind of contributions you don't want and encourage the kind of contributions you do want. Here are some possible preambles that prioritize different goals. We welcome a broad range of contributions from as many contributors as possible We encourage contributions from as many contributors as possible, and strive to make contributing easy and rewarding. We prefer to guide original contributors through the process of making necessary changes to any contributions, and reward mentoring and review. When a contribution is the combined effort of several people, we prefer to give primary credit to newer contributors. We give credit generously for all of the work that goes into making this project a success, including testing, review, debugging, mentoring, operations, documentation, and similar work. We welcome contributions that do not need much work We encourage contributions but our existing contributors have limited time to mentor or guide new contributors. When a contribution needs changes, existing contributors will usually make any necessary changes themselves rather than working with the original contributor to make the changes. However, we strive to give primary credit to the original contributor whenever possible. We especially encourage contributions that make it easier for new contributors to become productive without direct mentoring, such as documentation, tutorials, refactoring, tests, and similar. We accept outside contributions rarely Our priority is quality of contributions and architectural cohesion. We prefer contributions from existing contributors who are already familiar with our processes and standards, and are carrying out the architectural vision of our leaders. We do not mentor or guide new contributors. When existing contributors rewrite, reuse, or are inspired by contributions from new contributors, it is up to the existing contributor to decide how or if to credit the original author. We prioritize speed of development Our priority is speed of development. We reward contributors who send working contributions quickly. We prefer to give credit to the person who sends the first acceptable form of a contribution rather than the original contributor. Only bug fixes welcome [YOUR DRAFT HERE] My personal project subject to my personal whims [YOUR DRAFT HERE] Our corporate project not open to outside contributions [YOUR DRAFT HERE] Our research project not open to outside contributions [YOUR DRAFT HERE] [YOUR PREAMBLE HERE] Credit assignment options Here are a selection of possible rules for assigning credit. You should choose the ones that encourage the behavior you describe in your philosophy. For example, if you want to encourage new contributors, choose rules that give credit more generously to new contributors than existing ones. If you want existing contributors to have strong control over the project, choose rules that give credit more generously to people who edit or rewrite contributions. Note: don’t get too wrapped up in who “really wrote a contribution.” Most contributions are a collaborative effort by multiple people and it would be impossible to give credit to every single person who made a one line contribution to your project possible. Instead, focus on what behaviors you want to reward and which ones you want to discourage, and be creative about how you do that. If a contribution includes substantial work from multiple authors, we will give primary credit to the least experienced contributor. If we need to rewrite a contribution, we will give primary credit to the author of the first version and secondary credit to the person rewriting it. If we need to rewrite a contribution, we will give primary credit to the person rewriting it and secondary credit to the author of the first version. If we need to rewrite a contribution, we will work with the original author to make the necessary changes for as long as they respond in good faith and in a timely manner. In any case, the original author will get primary credit. The project leaders are the sole authority on who gets credit and will assign it to no one, to themselves, or to others as they see fit. [YOUR SUGGESTION HERE] Please make it easy for us to accept and credit your contribution! Here are the steps to take to get the most credit for your work: [CHOOSE APPLICABLE] Include “Signed-off-by: [YOUR NAME]” Agree to the CLA Follow the instructions in CONTRIBUTING Respond to requests for changes within N days Cooperate in good faith with our requests for changes If you do not want to make changes, please tell us as soon as possible [YOUR SUGGESTION HERE] If for some reasons you can’t or won’t make necessary changes to your contribution, we will [CHOOSE ONE OR MORE AND EDIT TO FIT] Reject your contribution and take no further action Incorporate your original contribution as is, then make a second change with any edits Incorporate your contribution along with any necessary edits with primary credit to the newest contributor, with a link in the change message to your original contribution on our mailing list or other archive of original contributions (e.g. a directory in the source code, a section of the wiki, etc.) If you did not [sign off, agree to the CLA, other necessary process step], we will rewrite from scratch and include a link to the original contribution in the change message How we give credit: For commits to a repository, the primary author is the commit author. For reviews, editing, testing, debugging, or reporting directly related to a specific contribution, we add a line in the change message such as “Reviewed-by” or “Edited-by”. For contributions that are not specific to an individual change, such as hosting, DevOps, DevRel, issue curation, etc, we will add your name to [LIST AND LOCATION OF PUBLICATION]. To be added to this list, please [INSTRUCTIONS]. [Suggestion: include an option for extremely minor contributions.] [YOUR SUGGESTION HERE] We reserve the right to not grant credit when it seems detrimental to our project. For example, if someone requests credit to a name that is obscene or harmful, or if they are spamming multiple projects with minor contributions, or if interacting with a contributor is demoralizing to other contributors. Correcting mistakes in credit Sometimes we make a mistake in how we give credit. In this project: [CHOOSE FROM FOLLOWING] Once credit had been given, we will not go back and correct it. We will correct mistakes in credit attribution for up to [TIME PERIOD] after credit has been given. We will correct mistakes in credit at any point. [YOUR SUGGESTIONS HERE] Reporting problems with credit If someone has not given credit correctly, please contact [CONTACT INFORMATION - COULD BE CODE OF CONDUCT COMMITTEE] and include any relevant information. [NAMES] will review your report and take any action they deem appropriate, including but not limited to updating the credit information, warning the person who did not follow the credit policy, no longer accepting their contributions, or forwarding the complaint to the community code of conduct committee.

4 4

Call for support of co-chair candidates
by Marcos Sanz 20 Dec '23

20 Dec '23

Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today's session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It's also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you'd wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it's your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter

27 36

Re: [opensource-wg] Call for support of co-chair candidates
by Bruno Banelli ＠ Racunarstvo 14 Dec '23

14 Dec '23

Greetings to everyone, pleasantly surprised with Luka's co-chair nomination, I truly believing he can contribute to the operations of the group and will make a fine addition to already fantastic people sitting there. That being said, I vote for: 1. Luka Perkov With my very best regards, Bruno Banelli, Algebra University College Zagreb On Thu, Nov 30, 2023 at 10:27 AM Marcos Sanz via opensource-wg <opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net>> wrote: Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today’s session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It’s also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you’d wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it’s your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter _______________________________________________ opensource-wg mailing list opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net> https://lists.ripe.net/mailman/listinfo/opensource-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

3 2

Re: [opensource-wg] Call for support of co-chair candidates
by Ines Skelac 14 Dec '23

14 Dec '23

Dear Colleagues, I am delighted to learn about Luka Perkov's nomination for the co-chair position. Given his capabilities and dedication, I am confident that he will be a valuable asset to the team. In light of this, I would like to formally cast my vote in favor of Luka Perkov for the co-chair role. Thank you for considering my recommendation. Warm regards, Ines Skelac, PhD, Assistant Professor Vice-dean for Science, International Cooperation, Management and Quality Assurance University of Zagreb, Faculty of Philosophy and Religious Studies www.ffrz.unizg.hr ines.skelac(a)ffrz.unizg.hr > On Thu, Nov 30, 2023 at 10:27 AM Marcos Sanz via opensource-wg < >> opensource-wg(a)ripe.net> wrote: >> >> Dear all, >> >> >> >> as explained today during the working group session, three people have >> volunteered to fill the one open co-chair vacancy. Sorted by sha256() over >> their full name, the candidates are >> >> >> >> -Christian Scheele >> >> -Luka Perkov >> >> -Sasha Romijn >> >> >> >> Big thanks to all of them for their offer to support the community, we >> are happy to see such an interest! The candidates have introduced >> themselves and their motivations also during today’s session. In case you >> missed it, you can watch the specific recordings here: >> >> https://ripe87.ripe.net/archives/video/1214 >> >> https://ripe87.ripe.net/archives/video/1217 >> >> >> >> >> >> Now this is a public call for support of the candidates, open for TWO >> WEEKS starting now and ENDING 14th December (EOB UTC). If you want to >> support one (or more) candidate(s), please send a public message doing so >> to this mailing list. Statements of support cannot be anonymous, so please >> finish the e-mail with your name. >> >> >> >> It’s also possible (even helpful) to support more than one candidate (to >> be able to break potential ties). If you’d wish to do so, please deliver >> your statement of support with the candidate names sorted by preference. >> >> >> >> Now it’s your time to contribute by choosing the new co-chair: help the >> community! >> >> Marcos Sanz & Martin Winter >> _______________________________________________ >> opensource-wg mailing list >> opensource-wg(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/opensource-wg >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://lists.ripe.net/mailman/listinfo/opensource-wg >> >> > > > > >

1 0