From c46d82e32e96585aea6dec33ac6bbe9a2f1999c0 Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 08:44:21 +0400 Subject: [PATCH 1/7] docs: add Turkish translation for security-best-practices guide --- ...ecurity-best-practices-for-your-project.md | 83 +++++++++---------- 1 file changed, 41 insertions(+), 42 deletions(-) diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md index a5d380f0831..9097069538e 100644 --- a/_articles/tr/security-best-practices-for-your-project.md +++ b/_articles/tr/security-best-practices-for-your-project.md @@ -1,84 +1,83 @@ --- lang: tr -untranslated: true -title: Security Best Practices for your Project -description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +title: Projeniz İçin Güvenlik En İyi Uygulamaları +description: MFA ve kod taramasından güvenli bağımlılık yönetimine ve özel güvenlik açığı raporlamasına kadar temel güvenlik uygulamalarıyla güven inşa ederek projenizin geleceğini güçlendirin. class: security-best-practices order: -1 image: /assets/images/cards/security-best-practices.png --- -Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. +Hatalar ve yeni özellikler bir yana, bir projenin uzun ömürlü olmasını belirleyen şey yalnızca faydalı olması değil, aynı zamanda kullanıcılarının güvenini kazanmasıdır. Güçlü güvenlik önlemleri, bu güveni sürdürmek için önemlidir. İşte projenizin güvenliğini önemli ölçüde artırmak için atabileceğiniz bazı önemli adımlar. -## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) +## Ayrıcalıklı tüm katılımcıların Çok Faktörlü Kimlik Doğrulama (MFA) etkinleştirdiğinden emin olun -### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages. +### Projenizde ayrıcalıklı bir katkıcıyı taklit etmeyi başaran kötü niyetli bir aktör, felakete yol açabilir. -Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. +Ayrıcalıklı erişim elde ettikten sonra, bu aktör kodunuzu değiştirebilir ve kodunuzun istenmeyen işlemler yapmasını (ör. kripto para madenciliği ve.b) sağlayabilir, kötü amaçlı yazılım dağıtabilir veya özel kod depolarınıza erişerek fikri mülkiyet ve hassas verileri, diğer hizmetlerin kimlik bilgileri dâhil olmak üzere, sızdırabilir. -MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. +MFA, hesap ele geçirmelere karşı ek bir güvenlik katmanı sağlar. Etkinleştirildiğinde, giriş yapmak için kullanıcı adı ve şifreye ek olarak yalnızca sizin bildiğiniz veya erişebildiğiniz başka bir doğrulama yöntemi gerekir. -## Secure your code as part of your development workflow +## Kodunuzu geliştirme sürecinizin bir parçası olarak güvene alın -### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. +### Kodunuzdaki güvenlik açıkları, dağıtımda fark edilmesine kıyasla, erken aşamalarda tespit edildiğinde çok daha ucuza çözülebilir. -Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. +Kodunuzdaki güvenlik açıklarını tespit etmek için Statik Uygulama Güvenliği Testi (SAST) aracı kullanın. Bu araçlar kod seviyesinde çalışır, yürütme ortamına ihtiyaç duymaz ve bu nedenle sürecin erken aşamalarında çalıştırılabilir; ayrıca build veya kod inceleme aşamalarına sorunsuzca entegre edilebilir. -It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. +Bu, adeta kod deponuzu gözden geçiren, gizlenmiş güvenlik açıklarını sizin için bulan yetenekli bir uzmana sahip olmak gibidir. -How to choose your SAST tool? -Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. -Check the coverage for your language(s) +SAST aracınızı nasıl seçersiniz? +- Lisansı kontrol edin: Bazı araçlar açık kaynak projeleri için ücretsizdir (ör. GitHub CodeQL veya SemGrep). +- Kullandığınız dili/dilleri destekleyip desteklemediğini kontrol edin. -* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. -* Beware of False Positives! You don't want the tool to slow you down for no reason! -* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). +* Halihazırda kullandığınız araç ve süreçlere kolayca entegre olabilen birini seçin. Örneğin, uyarılar kod inceleme aracınızda görünsün, başka bir platforma gitmeniz gerekmesin. +* Yanlış pozitiflere dikkat edin! Araç sizi boş yere yavaşlatmamalı. +* Özelliklerini inceleyin: Bazıları çok güçlüdür ve veri akışı takibi yapabilir (ör. GitHub CodeQL), bazıları yapay zekâ ile çözüm önerileri sunar, bazıları özel sorgular yazmayı kolaylaştırır (ör. SemGrep). -## Don't share your secrets +## Sırlarınızı paylaşmayın -### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. +### API anahtarları, tokenlar ve parolalar gibi hassas veriler bazen yanlışlıkla repoya yüklenebilir. -Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. +Şöyle bir senaryo hayal edin: Dünyanın dört bir yanından katkıcıların bulunduğu popüler bir açık kaynak projesinin sahibisiniz. Bir gün, bir katkıcı farkında olmadan üçüncü taraf bir servise ait API anahtarlarını repoya yükler. Günler sonra birileri bu anahtarları bulur ve izinsiz şekilde servise erişir. Servis tehlikeye girer, kullanıcılar kesinti yaşar ve projenizin itibarı zedelenir. -To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. +Bunu önlemek için “gizli tarama” (secret scanning) çözümleri vardır. GitHub Secret Scanning veya Truffle Security’nin Trufflehog aracı, bu tür bilgileri repoya göndermenizi engelleyebilir. Bazı araçlar, belirli sırları otomatik olarak iptal de edebilir. -## Check and update your dependencies +## Bağımlılıkları kontrol edin ve güncelleyin -### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. +### Projenizdeki bağımlılıklar, projenizin güvenliğini tehlikeye atan açıklar içerebilir. Bunları manuel olarak güncel tutmak zaman alıcı olabilir. -Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. +Şöyle düşünün: Sık kullanılan bir kütüphane üzerine inşa edilen bir proje var. Daha sonra bu kütüphanede ciddi bir güvenlik açığı bulundu, fakat uygulamayı geliştirenler bundan haberdar değil. Hassas veriler saldırganların eline geçer. Bu yalnızca teorik bir senaryo değil. 2017’de Equifax, Apache Struts bağımlılığını güncellemedi ve 144 milyon kullanıcının verilerini etkileyen meşhur ihlal yaşandı. -To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. +Bunu önlemek için Dependabot ve Renovate gibi Yazılım Bileşen Analizi (SCA) araçları, bağımlılıklarınızı NVD veya GitHub Advisory Database gibi açık veritabanlarıyla karşılaştırarak bilinen güvenlik açıklarını bulur ve güvenli sürümlere güncellemek için otomatik PR oluşturur. -## Avoid unwanted changes with protected branches +## Korunan dallarla istenmeyen değişiklikleri engelleyin -### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. +### Ana dallara sınırsız erişim, yanlışlıkla veya kötü niyetli yapılan değişikliklerin güvenlik açıklarına veya projenizin kararlılığını bozmasına yol açabilir. -A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. +Yeni bir katkıcı ana dala yazma izni alır ve test edilmemiş değişiklikleri doğrudan gönderir. Ardından ciddi bir güvenlik açığı ortaya çıkar. Bunu önlemek için dal koruma kuralları kullanın. Bu kurallar sayesinde önemli dallara gözden geçirilmeden veya belirli kontrolleri geçmeden hiçbir değişiklik birleştirilemez. -## Set up an intake mechanism for vulnerability reporting +## Güvenlik açığı raporları için bir bildirim mekanizması oluşturun -### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? +### Kullanıcıların hata raporlamasını kolaylaştırmak iyi bir uygulamadır, ancak bu hatanın güvenlik riski etkisi olduğunda bunu size nasıl güvenle iletebilirler? -Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. +Şöyle bir durum düşünün: Bir güvenlik araştırmacısı projenizde açık buldu ama bunu bildirecek güvenli bir yol yok. Belki GitHub’da herkese açık bir issue açar ya da sosyal medyada paylaşır. Hatta iyi niyetle bir PR bile gönderebilir ama bu açık, herkes tarafından görülmeden birleşmez. Bu da kötü niyetli kişilerin açığı istismar etmesine yol açabilir. -### Security Policy +### Güvenlik Politikası -To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. +Bunu önlemek için bir güvenlik politikası yayınlayın. `SECURITY.md` dosyasında belirtilen bu politika, güvenlik sorunlarının nasıl raporlanacağını, kimlerin sorumlu olduğunu ve sürecin nasıl işleyeceğini netleştirir. Basitçe “Lütfen herkese açık issue veya PR açmayın, security@example.com adresine mail gönderin” bile yazabilirsiniz. Daha fazla detay da ekleyebilirsiniz (ör. size ne kadar sürede dönüş yapılacağını). -### Private Vulnerability Reporting +### Özel Güvenlik Açığı Raporlama -On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. +Bazı platformlar süreci daha güvenli hale getirmek için özel raporlama sağlar. GitLab’da “private issues”, GitHub’da ise “private vulnerability reporting (PVR)” vardır. PVR ile bakımcılar güvenlik açıklarını özel şekilde alıp çözebilir. GitHub otomatik olarak özel bir fork açar, güvenlik tavsiyesi taslağı oluşturur. Tüm süreç siz açıklayana kadar gizli kalır. Sonrasında güvenlik danışmanlığı yayınlanır ve kullanıcılarınız SCA araçları sayesinde korunur. -## Conclusion: A few steps for you, a huge improvement for your users +## Sonuç: Küçük adımlar, büyük güvenlik -These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. +Bu birkaç adım size basit veya sıradan görünebilir, ancak kullanıcılarınız için projenizi çok daha güvenli hale getirir. Çünkü en yaygın sorunlara karşı koruma sağlar. -## Contributors +## Katkıcılar -### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! +### Bu kılavuzu hazırlarken deneyim ve ipuçlarını paylaşan tüm bakımcılara teşekkürler! -This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: +Bu kılavuz [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) tarafından yazıldı, katkıda bulunanlar: [@JLLeitschuh](https://github.com/JLLeitschuh) -[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others! +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! \ No newline at end of file From 6ac664b64f815d02f0e3a258afd2a245ce856ac0 Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 10:25:02 +0400 Subject: [PATCH 2/7] docs: add Turkish translation for maintaining balance for Open Source Maintainers --- ...ing-balance-for-open-source-maintainers.md | 151 +++++------------- 1 file changed, 38 insertions(+), 113 deletions(-) diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md index dc2cf3ec1ec..8b0b1d50d31 100644 --- a/_articles/tr/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md @@ -1,6 +1,5 @@ --- lang: tr -untranslated: true title: Açık Kaynak Geliştiricileri için Dengeyi Korumak description: Bir açık kaynak geliştiricisi olarak öz bakım ve tükenmişlikten kaçınmak için ipuçları. class: balance @@ -10,161 +9,87 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png Açık kaynaklı bir projenin popülaritesi arttıkça, uzun vadede yenilenmiş ve üretken kalmak için dengeyi korumanıza yardımcı olacak net sınırlar belirlemek önemli hale gelir. -Bakımcıların deneyimleri ve dengeyi bulma stratejileri hakkında bilgi edinmek için Bakımcı Topluluğu'nun 40 üyesiyle bir atölye çalışması gerçekleştirdik ve açık kaynakta tükenmişlikle ilgili ilk elden deneyimlerini ve işlerinde dengeyi korumalarına yardımcı olan uygulamaları öğrenmemizi sağladık. Kişisel ekoloji kavramı burada devreye giriyor. +Bakımcıların deneyimleri ve dengeyi bulma stratejileri hakkında bilgi edinmek için Bakımcı Topluluğu'nun 40 üyesiyle bir atölye çalışması gerçekleştirdik ve açık kaynakta tükenmişlikle ilgili ilk elden deneyimlerini ve işlerinde dengeyi korumalarına yardımcı olan uygulamaları öğrenmemizi sağladık. Kişisel ekoloji kavramı burada devreye giriyor. -So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with. +Kişisel ekoloji nedir? Rockwood Leadership Institute'nin tanımına göre, "enerjinizi uzun bir aktivizm süresince sürdürebilmek için dengeyi, tempoyu ve verimliliği korumak" anlamına gelir. Bu, bakımcıların katkılarını daha geniş bir ekosistemin parçası olarak görmelerine yardımcı oldu. Dünya Sağlık Örgütü'nün (WHO) tanımına göre kronik iş stresi sonucu ortaya çıkan tükenmişlik, bakımcılar arasında yaygındır. Bu durum motivasyon kaybı, odaklanamama ve katkıda bulunduğunuz topluluğa empati gösterememe ile sonuçlanabilir. -By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work. +Kişisel ekoloji kavramını benimseyerek, bakımcılar tükenmişliği önleyebilir, öz bakım önceliklerini koruyabilir ve dengeli bir şekilde en iyi işleri yapabilir. -## Tips for Self-Care and Avoiding Burnout as a Maintainer: +## Bakımcılar için Öz Bakım ve Tükenmişlikten Kaçınma İpuçları -### Identify your motivations for working in open source +### Açık kaynakta çalışmaktaki motivasyonlarınızı belirleyin -Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus. +Açık kaynak bakımında sizi hangi noktaların enerjilendirdiğini düşünün. Motivasyonlarınızı anlamak, işlerinizi ilgi ve motivasyonunuzu koruyacak şekilde önceliklendirmeye yardımcı olur. Kullanıcı geri bildirimlerinden, toplulukla işbirliği ve sosyalleşme keyfinden veya koda dalmanın tatmininden ilham alabilirsiniz. -### Reflect on what causes you to get out of balance and stressed out +### Dengenizi bozup stres yaratan etmenleri gözden geçirin -It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: +Tükenmişliğe neyin sebep olduğunu anlamak önemlidir. Açık kaynak bakımcıları arasında sıkça rastlanan bazı durumlar: -* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. +* **Olumlu geri bildirim eksikliği:** Kullanıcılar yalnızca şikayetleri olduğunda iletişime geçer. Her şey iyi çalışıyorsa sessiz kalırlar. Giderek artan bir sorun listesi görmek, katkılarınızın fark yaratıp yaratmadığını gösteren geri bildirimlerin eksikliği moral bozabilir. -* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations. +* **'Hayır' diyememek:** Açık kaynak projesinde gereğinden fazla sorumluluk almak kolaydır. Kullanıcılardan, katkıda bulunanlardan veya diğer bakımcılardan gelen beklentilerle başa çıkmak zor olabilir. -* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. +* **Yalnız çalışmak:** Bakımcı olmak son derece yalnız bir süreç olabilir. Bir grup bakımcı ile çalışsanız bile, son birkaç yılda dağıtık ekipleri yüz yüze toplamak zor olmuştur. -* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. +* **Yetersiz zaman veya kaynak:** Gönüllü bakımcılar için, projeye çalışmak için kendi boş zamanlarını feda etmek zorunda kalmak yaygındır. - - -* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community. - - - -### Watch out for signs of burnout - -Can you keep up your pace for 10 weeks? 10 months? 10 years? - -There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress). - - - -### What would you need to continue sustaining yourself and your community? - -This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard: - -* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. - - You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work. - -* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/). - - +* **Çelişen talepler:** Açık kaynak farklı motivasyonlara sahip gruplardan oluşur ve bu durum bazen zorlayıcı olabilir. Ücretli olarak açık kaynak çalışıyorsanız, işverenin çıkarları topluluğun çıkarlarıyla çatışabilir. -* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions. +### Tükenmişlik belirtilerine dikkat edin - +Kendi temponuzu 10 hafta, 10 ay veya 10 yıl sürdürebiliyor musunuz? -* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term. +[@shaunagm](https://github.com/shaunagm) tarafından hazırlanan [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) gibi araçlar, mevcut temponuzu gözden geçirip ayarlama yapmanıza yardımcı olabilir. Bazı bakımcılar uyku kalitesi ve kalp atış hızı değişkenliği gibi ölçümleri takip etmek için giyilebilir teknoloji kullanır. - If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. +### Kendinizi ve topluluğunuzu sürdürebilmek için neye ihtiyacınız var? - +Her bakımcı için farklıdır ve yaşam evresi ve diğer faktörlere bağlı olarak değişir. Duyduğumuz bazı temalar: -* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time. +* **Topluluğa güvenin:** İş yükünü azaltmak için delegasyon yapın ve katkıda bulunanlar bulun. Bir projede birden fazla temas noktası, mola verirken rahat etmenizi sağlar. - +* **Fon kaynaklarını araştırın:** Açık kaynak çalışmalarınız için maddi destek arayın. [GitHub Sponsors](https://github.com/sponsors) veya [GitHub Accelerator](http://accelerator.github.com/) gibi programlar başlangıç için uygundur. - Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about. +* **Araçları kullanın:** Günlük işleri otomatikleştirmek için [GitHub Copilot](https://github.com/features/copilot/) ve [GitHub Actions](https://github.com/features/actions) gibi araçları keşfedin. - +* **Dinlenin ve yenilenin:** Hobilerinize zaman ayırın, hafta sonlarını dinlenmeye ayırın ve GitHub durumunuzu güncelleyin. - +* **Sınırlar koyun:** Her isteğe evet demeyin. Yapmak istediklerinizi ve yapmayacaklarınızı belirtin. -Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run. +Unutmayın, kişisel ekoloji sürekli gelişen bir uygulamadır ve açık kaynak yolculuğunuzda ilerledikçe evrilecektir. Öz bakım öncelikli olmak ve dengeyi korumak, açık kaynak topluluğuna etkili ve sürdürülebilir katkı sağlamanızı garanti eder. -## Additional Resources +## Ek Kaynaklar * [Maintainer Community](http://maintainers.github.com/) * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon @@ -174,13 +99,13 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) * [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid * [Governing Open](https://governingopen.com/) -* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series +* Workshop gündemi [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) serisinden uyarlanmıştır -## Contributors +## Katkıda Bulunanlar -Many thanks to all the maintainers who shared their experiences and tips with us for this guide! +Bu rehberi hazırlarken deneyimlerini ve ipuçlarını paylaşan tüm bakımcılara teşekkür ederiz! -This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: +Bu rehber [@abbycabs](https://github.com/abbycabs) tarafından yazılmıştır, katkılarından dolayı: [@agnostic-apollo](https://github.com/agnostic-apollo) [@AndreaGriffiths11](https://github.com/AndreaGriffiths11) @@ -217,4 +142,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu [@thisisnic](https://github.com/thisisnic) [@tudoramariei](https://github.com/tudoramariei) [@UlisesGascon](https://github.com/UlisesGascon) -[@waldyrious](https://github.com/waldyrious) + many others! +[@waldyrious](https://github.com/waldyrious) + diğerleri \ No newline at end of file From 796754a9e143d30b2feb827208ad9eb00ccb796b Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 11:14:47 +0400 Subject: [PATCH 3/7] Add workflow to fix file permissions --- .github/workflows/fix-permissions.yml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 .github/workflows/fix-permissions.yml diff --git a/.github/workflows/fix-permissions.yml b/.github/workflows/fix-permissions.yml new file mode 100644 index 00000000000..1eca093501b --- /dev/null +++ b/.github/workflows/fix-permissions.yml @@ -0,0 +1,24 @@ +name: Fix File Permissions + +on: + pull_request: + branches: + - main + +jobs: + fix-permissions: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - name: Set correct file permissions + run: | + find . -type f -exec chmod 644 {} \; + find . -type d -exec chmod 755 {} \; + - name: Commit permission changes + run: | + git config --global user.name "github-actions" + git config --global user.email "github-actions@github.com" + git add -A + git commit -m "Fix file permissions" || echo "No changes to commit" + git push + From acc67d90d3960f8688b535f7c72347c8968799df Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 11:34:49 +0400 Subject: [PATCH 4/7] Delete fix permission workflow --- .github/workflows/fix-permissions.yml | 24 ------------------------ 1 file changed, 24 deletions(-) delete mode 100644 .github/workflows/fix-permissions.yml diff --git a/.github/workflows/fix-permissions.yml b/.github/workflows/fix-permissions.yml deleted file mode 100644 index 1eca093501b..00000000000 --- a/.github/workflows/fix-permissions.yml +++ /dev/null @@ -1,24 +0,0 @@ -name: Fix File Permissions - -on: - pull_request: - branches: - - main - -jobs: - fix-permissions: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v3 - - name: Set correct file permissions - run: | - find . -type f -exec chmod 644 {} \; - find . -type d -exec chmod 755 {} \; - - name: Commit permission changes - run: | - git config --global user.name "github-actions" - git config --global user.email "github-actions@github.com" - git add -A - git commit -m "Fix file permissions" || echo "No changes to commit" - git push - From 8aca92ff9455844be3482f5d2ded1b2d2f768839 Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 11:44:08 +0400 Subject: [PATCH 5/7] minor update --- _articles/tr/maintaining-balance-for-open-source-maintainers.md | 2 +- _articles/tr/security-best-practices-for-your-project.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md index 8b0b1d50d31..1f61dde2500 100644 --- a/_articles/tr/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md @@ -142,4 +142,4 @@ Bu rehber [@abbycabs](https://github.com/abbycabs) tarafından yazılmıştır, [@thisisnic](https://github.com/thisisnic) [@tudoramariei](https://github.com/tudoramariei) [@UlisesGascon](https://github.com/UlisesGascon) -[@waldyrious](https://github.com/waldyrious) + diğerleri \ No newline at end of file +[@waldyrious](https://github.com/waldyrious) + diğerleri diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md index 9097069538e..9f652f5b442 100644 --- a/_articles/tr/security-best-practices-for-your-project.md +++ b/_articles/tr/security-best-practices-for-your-project.md @@ -80,4 +80,4 @@ Bu birkaç adım size basit veya sıradan görünebilir, ancak kullanıcıların Bu kılavuz [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) tarafından yazıldı, katkıda bulunanlar: [@JLLeitschuh](https://github.com/JLLeitschuh) -[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! \ No newline at end of file +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! From 0d0892cfaa8cbdcac8a867e2dc98c069fff52aee Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 19:39:20 +0400 Subject: [PATCH 6/7] minor updates --- ...ecurity-best-practices-for-your-project.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md index 9f652f5b442..7040634a8f5 100644 --- a/_articles/tr/security-best-practices-for-your-project.md +++ b/_articles/tr/security-best-practices-for-your-project.md @@ -13,22 +13,22 @@ Hatalar ve yeni özellikler bir yana, bir projenin uzun ömürlü olmasını bel ### Projenizde ayrıcalıklı bir katkıcıyı taklit etmeyi başaran kötü niyetli bir aktör, felakete yol açabilir. -Ayrıcalıklı erişim elde ettikten sonra, bu aktör kodunuzu değiştirebilir ve kodunuzun istenmeyen işlemler yapmasını (ör. kripto para madenciliği ve.b) sağlayabilir, kötü amaçlı yazılım dağıtabilir veya özel kod depolarınıza erişerek fikri mülkiyet ve hassas verileri, diğer hizmetlerin kimlik bilgileri dâhil olmak üzere, sızdırabilir. +Ayrıcalıklı erişim elde ettikten sonra, bu aktör kodunuzu değiştirebilir ve kodunuzun istenmeyen işlemler yapmasını (ör. kripto para madenciliği vb.) sağlayabilir, kötü amaçlı yazılım dağıtabilir veya özel kod depolarınıza erişerek fikri mülkiyet ve hassas verileri, diğer hizmetlerin kimlik bilgileri dâhil olmak üzere, sızdırabilir. MFA, hesap ele geçirmelere karşı ek bir güvenlik katmanı sağlar. Etkinleştirildiğinde, giriş yapmak için kullanıcı adı ve şifreye ek olarak yalnızca sizin bildiğiniz veya erişebildiğiniz başka bir doğrulama yöntemi gerekir. ## Kodunuzu geliştirme sürecinizin bir parçası olarak güvene alın -### Kodunuzdaki güvenlik açıkları, dağıtımda fark edilmesine kıyasla, erken aşamalarda tespit edildiğinde çok daha ucuza çözülebilir. +### Kodunuzdaki güvenlik açıkları, dağıtımda fark edilmesine kıyasla, erken aşamalarda tespit edildiğinde çok daha ucuza çözülebilir. Kodunuzdaki güvenlik açıklarını tespit etmek için Statik Uygulama Güvenliği Testi (SAST) aracı kullanın. Bu araçlar kod seviyesinde çalışır, yürütme ortamına ihtiyaç duymaz ve bu nedenle sürecin erken aşamalarında çalıştırılabilir; ayrıca build veya kod inceleme aşamalarına sorunsuzca entegre edilebilir. Bu, adeta kod deponuzu gözden geçiren, gizlenmiş güvenlik açıklarını sizin için bulan yetenekli bir uzmana sahip olmak gibidir. SAST aracınızı nasıl seçersiniz? -- Lisansı kontrol edin: Bazı araçlar açık kaynak projeleri için ücretsizdir (ör. GitHub CodeQL veya SemGrep). -- Kullandığınız dili/dilleri destekleyip desteklemediğini kontrol edin. +* Lisansı kontrol edin: Bazı araçlar açık kaynak projeleri için ücretsizdir (ör. GitHub CodeQL veya SemGrep). +* Kullandığınız dili/dilleri destekleyip desteklemediğini kontrol edin. * Halihazırda kullandığınız araç ve süreçlere kolayca entegre olabilen birini seçin. Örneğin, uyarılar kod inceleme aracınızda görünsün, başka bir platforma gitmeniz gerekmesin. * Yanlış pozitiflere dikkat edin! Araç sizi boş yere yavaşlatmamalı. * Özelliklerini inceleyin: Bazıları çok güçlüdür ve veri akışı takibi yapabilir (ör. GitHub CodeQL), bazıları yapay zekâ ile çözüm önerileri sunar, bazıları özel sorgular yazmayı kolaylaştırır (ör. SemGrep). @@ -39,13 +39,13 @@ SAST aracınızı nasıl seçersiniz? Şöyle bir senaryo hayal edin: Dünyanın dört bir yanından katkıcıların bulunduğu popüler bir açık kaynak projesinin sahibisiniz. Bir gün, bir katkıcı farkında olmadan üçüncü taraf bir servise ait API anahtarlarını repoya yükler. Günler sonra birileri bu anahtarları bulur ve izinsiz şekilde servise erişir. Servis tehlikeye girer, kullanıcılar kesinti yaşar ve projenizin itibarı zedelenir. -Bunu önlemek için “gizli tarama” (secret scanning) çözümleri vardır. GitHub Secret Scanning veya Truffle Security’nin Trufflehog aracı, bu tür bilgileri repoya göndermenizi engelleyebilir. Bazı araçlar, belirli sırları otomatik olarak iptal de edebilir. +Bunu önlemek için "gizli tarama" (secret scanning) çözümleri vardır. GitHub Secret Scanning veya Truffle Security'nin Trufflehog aracı, bu tür bilgileri repoya göndermenizi engelleyebilir. Bazı araçlar, belirli sırları otomatik olarak iptal de edebilir. ## Bağımlılıkları kontrol edin ve güncelleyin ### Projenizdeki bağımlılıklar, projenizin güvenliğini tehlikeye atan açıklar içerebilir. Bunları manuel olarak güncel tutmak zaman alıcı olabilir. -Şöyle düşünün: Sık kullanılan bir kütüphane üzerine inşa edilen bir proje var. Daha sonra bu kütüphanede ciddi bir güvenlik açığı bulundu, fakat uygulamayı geliştirenler bundan haberdar değil. Hassas veriler saldırganların eline geçer. Bu yalnızca teorik bir senaryo değil. 2017’de Equifax, Apache Struts bağımlılığını güncellemedi ve 144 milyon kullanıcının verilerini etkileyen meşhur ihlal yaşandı. +Şöyle düşünün: Sık kullanılan bir kütüphane üzerine inşa edilen bir proje var. Daha sonra bu kütüphanede ciddi bir güvenlik açığı bulundu, fakat uygulamayı geliştirenler bundan haberdar değil. Hassas veriler saldırganların eline geçer. Bu yalnızca teorik bir senaryo değil. 2017'de Equifax, Apache Struts bağımlılığını güncellemedi ve 144 milyon kullanıcının verilerini etkileyen meşhur ihlal yaşandı. Bunu önlemek için Dependabot ve Renovate gibi Yazılım Bileşen Analizi (SCA) araçları, bağımlılıklarınızı NVD veya GitHub Advisory Database gibi açık veritabanlarıyla karşılaştırarak bilinen güvenlik açıklarını bulur ve güvenli sürümlere güncellemek için otomatik PR oluşturur. @@ -59,15 +59,15 @@ Yeni bir katkıcı ana dala yazma izni alır ve test edilmemiş değişiklikleri ### Kullanıcıların hata raporlamasını kolaylaştırmak iyi bir uygulamadır, ancak bu hatanın güvenlik riski etkisi olduğunda bunu size nasıl güvenle iletebilirler? -Şöyle bir durum düşünün: Bir güvenlik araştırmacısı projenizde açık buldu ama bunu bildirecek güvenli bir yol yok. Belki GitHub’da herkese açık bir issue açar ya da sosyal medyada paylaşır. Hatta iyi niyetle bir PR bile gönderebilir ama bu açık, herkes tarafından görülmeden birleşmez. Bu da kötü niyetli kişilerin açığı istismar etmesine yol açabilir. +Şöyle bir durum düşünün: Bir güvenlik araştırmacısı projenizde açık buldu ama bunu bildirecek güvenli bir yol yok. Belki GitHub'da herkese açık bir issue açar ya da sosyal medyada paylaşır. Hatta iyi niyetle bir PR bile gönderebilir ama bu açık, herkes tarafından görülmeden birleşmez. Bu da kötü niyetli kişilerin açığı istismar etmesine yol açabilir. ### Güvenlik Politikası -Bunu önlemek için bir güvenlik politikası yayınlayın. `SECURITY.md` dosyasında belirtilen bu politika, güvenlik sorunlarının nasıl raporlanacağını, kimlerin sorumlu olduğunu ve sürecin nasıl işleyeceğini netleştirir. Basitçe “Lütfen herkese açık issue veya PR açmayın, security@example.com adresine mail gönderin” bile yazabilirsiniz. Daha fazla detay da ekleyebilirsiniz (ör. size ne kadar sürede dönüş yapılacağını). +Bunu önlemek için bir güvenlik politikası yayınlayın. `SECURITY.md` dosyasında belirtilen bu politika, güvenlik sorunlarının nasıl raporlanacağını, kimlerin sorumlu olduğunu ve sürecin nasıl işleyeceğini netleştirir. Basitçe "Lütfen herkese açık issue veya PR açmayın, security@example.com adresine mail gönderin" bile yazabilirsiniz. Daha fazla detay da ekleyebilirsiniz (ör. size ne kadar sürede dönüş yapılacağını). ### Özel Güvenlik Açığı Raporlama -Bazı platformlar süreci daha güvenli hale getirmek için özel raporlama sağlar. GitLab’da “private issues”, GitHub’da ise “private vulnerability reporting (PVR)” vardır. PVR ile bakımcılar güvenlik açıklarını özel şekilde alıp çözebilir. GitHub otomatik olarak özel bir fork açar, güvenlik tavsiyesi taslağı oluşturur. Tüm süreç siz açıklayana kadar gizli kalır. Sonrasında güvenlik danışmanlığı yayınlanır ve kullanıcılarınız SCA araçları sayesinde korunur. +Bazı platformlar süreci daha güvenli hale getirmek için özel raporlama sağlar. GitLab'da "private issues", GitHub'da ise "private vulnerability reporting (PVR)" vardır. PVR ile bakımcılar güvenlik açıklarını özel şekilde alıp çözebilir. GitHub otomatik olarak özel bir fork açar, güvenlik tavsiyesi taslağı oluşturur. Tüm süreç siz açıklayana kadar gizli kalır. Sonrasında güvenlik danışmanlığı yayınlanır ve kullanıcılarınız SCA araçları sayesinde korunur. ## Sonuç: Küçük adımlar, büyük güvenlik @@ -79,5 +79,5 @@ Bu birkaç adım size basit veya sıradan görünebilir, ancak kullanıcıların Bu kılavuz [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) tarafından yazıldı, katkıda bulunanlar: -[@JLLeitschuh](https://github.com/JLLeitschuh) -[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! \ No newline at end of file From 64981ba7a66bceb8582707a460f0f88937d5445d Mon Sep 17 00:00:00 2001 From: samirrhashimov Date: Fri, 12 Sep 2025 19:43:33 +0400 Subject: [PATCH 7/7] minor updates --- _articles/tr/security-best-practices-for-your-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md index 7040634a8f5..e957093ab1b 100644 --- a/_articles/tr/security-best-practices-for-your-project.md +++ b/_articles/tr/security-best-practices-for-your-project.md @@ -80,4 +80,4 @@ Bu birkaç adım size basit veya sıradan görünebilir, ancak kullanıcıların Bu kılavuz [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) tarafından yazıldı, katkıda bulunanlar: [@JLLeitschuh](https://github.com/JLLeitschuh) -[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! \ No newline at end of file +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi!