রক্ষণাবেক্ষণকারী বলতে কী বোঝায়?

আপনি যদি একটি ওপেন সোর্স প্রকল্প রক্ষণাবেক্ষণ করেন যেটা অনেক লোক ব্যবহার করে, আপনি হয়ত লক্ষ্য করেছেন যে আপনি কম কোডিং করছেন এবং সমস্যাগুলিতে বেশি সাড়া দিচ্ছেন।

একটি প্রকল্পের প্রাথমিক পর্যায়ে, আপনি নতুন নতুন পরিকল্পনা নিয়ে পরীক্ষা-নিরীক্ষা করবেন এবং আপনার ইচ্ছার উপর ভিত্তি করে সিদ্ধান্ত নিবেন। কিন্তু আপনার প্রকল্পের জনপ্রিয়তা বাড়ার সাথে সাথে আপনি নিজেকে আপনার ব্যবহারকারী এবং অবদানকারীদের সাথে বেশি কাজ করতে দেখবেন।

একটা প্রকল্প রক্ষণাবেক্ষণ করতে কোডিং করার থেকেও বেশি কিছুর প্রয়োজন। এই কাজগুলো বেশির ভাগ সময়ই অপ্রত্যাশিত হয়ে থাকে, কিন্তু এগুলো প্রকল্প বড় করার মতোই সমান গুরুত্তপূর্ণ্য। নথিপত্র পক্রিয়াকরন থেকে শুরু করে সম্প্রদায়কে উন্নত করার ক্ষেত্রে, অপনার জীবনকে সহজ করার জন্য আমরা কিছু উপায় একত্রিত করেছি।

আপনার প্রক্রিয়া নথিভুক্ত করা

রক্ষণাবেক্ষণকারি হিসেবে আপনার সব থেকে গুরুত্তপূর্ণ্য কাজগুলোর মধ্যে একটি হচ্ছে লিখে রাখা।

নথিভূক্ত করা শুধুমাত্র আপনার নিজের চিন্তাভাবনাকে স্পষ্ট করে না, এটি অন্যদেরকে আপনার কাছে জানতে চাওয়ার আগেই আপনার প্রয়োজন বা প্রত্যাশা বুঝতে সাহায্য করে।

যখন কোন কিছু আপনার লক্ষের সাথে না মিলে, তখন নথিপত্র লেখা থাকলে না বলতে সুবিধা হয়। এটা অন্যদেরকে আপনার সাথে একসাথে কাজ করা এবং সাহায্য করাকেও সহজ করে দেয়। আপনি কখনোই জানবেন না কে আপনার প্রকল্প পড়তে অথবা ব্যবহার করতে পারে।

যদি আপনি সম্পূর্ণ্য বিস্তারিত ভাবে নাও লিখেন, তবে একদম না লেখার থেকে খসড়া বুলেট পয়েন্ট আকারে লেখা ভাল।

আপনার নথিপত্র হালনাগাদ(আপডেট) করতে ভুলবেন না। আপনি যদি সর্বদা এটা করতে নাও পারেন তবে আপনার পুরানো নথিগুলো মুছুন অথবা এটি পুরানো বলে চিহ্নিত করুন যাতে অবদানকারীরা জানে যে এখানে পুরাতন নথি হালনাগাদ করার মাধ্যমে তারা এই প্রকল্পে অবদান রাখতে পারে৷

আপনার কর্ম-পরিকল্পনা লিখুন

আপনার প্রকল্পের লক্ষ্যগুলো লেখার মাধ্যমে শুরু করুন। এগুলো আপনার রিডমি(README) ফাইলে সংযুক্ত করুন, অথবা ভিশন(VISION) নামে আলাদা ফাইল তৈরি করুন। যদি অন্য কোন গুরুত্তপুর্ণ্য জিনিস থাকে যেটা অন্যদের সাহায্য করবে যেমন প্রকল্পের রোডম্যাপ ইত্যাদি, সেগুলো সবার জন্য উন্মুক্ত করে দিন।

একটি স্পষ্ট এবং নথিভূক্ত কর্ম-পরিকল্পনা আপনাকে প্রকৃত লক্ষে অবিচল রাখবে এবং অন্যান্য অবদানকারীদের মাধ্যমে “scope creep” হওয়া অর্থাৎ প্রকৃত লক্ষ্য থেকে ধীরে ধীরে দূরে সরে যাওয়া এড়াতে সাহায্য করবে।

উদাহরণস্বরূপ @lord আবিষ্কার করলো যে একটি প্রকল্পের কর্ম-পরিকল্পনা তাকে বুঝতে সাহায্য করে কোন অনুরোধগুলিতে(requests) সময় ব্যয় করা উচিত। যখন সে প্রথম Slate এর ফিচার(বৈশিষ্ট) সংযুক্ত করার অনুরোধ পায় এবং যে তার প্রকল্পের লক্ষ্য থেকে দূরে সরে যায়, তখন সে একজন নতুন রক্ষণাবেক্ষণকারী হিসেবে অনুতপ্ত হয়।

অন্যদেরকে আপনার প্রত্যাশাগুলো জানান

নিয়মকানুন(Rules) লিপিবদ্ধ করা খুবই যন্ত্রণাদায়ক। অনেক সময় আপনার মনে হতে পারে আপনি অন্যদের আচরণ তদারকি করছেন অথবা সকল আনন্দ-বিনোদনের গলা চেপে ধরছেন।

যদি নিয়মকানুন লিপিবদ্ধ করা এবং ন্যায্য ভাবে প্রয়োগ করা হয়, যতকিছুই হোক, ভাল নিয়মকানুন রক্ষণাবেক্ষণকারীদের ক্ষমতা বৃদ্ধি করে। এটা আপনাকে এমন কাজ করতে বাধ্য হওয়া থেকে রক্ষা করে যা আপনি করতে চান না।

আপনার প্রকল্পের বেশির ভাগ মানুষ আপনার বা আপনার পরিস্থিতি সম্পর্কে কিছুই জানে না। তারা মনে করতে পারে যে আপনি এটি নিয়ে কাজ করার জন্য টাকা পান, বিশেষ করে যদি এটি এমন কিছু হয় যা তারা নিয়মিত ব্যবহার করে এবং নির্ভর করে। হয়তো এক সময় আপনি আপনার প্রকল্পে অনেক সময় দিয়েছিলেন, কিন্তু এখন আপনি নতুন চাকরি বা পরিবার সদস্যদের নিয়ে ব্যস্ত।

এগুলোর সবই পুরপুরি ঠিক আছে! শুধু এটা নিশ্চিত করুন যে অন্যরা আপনার পরিস্থিতিগুলো যেন জানে।

প্রকল্প রক্ষণাবেক্ষণ যদি আপনার পার্ট-টাইম বা সম্পূর্ণভাবে স্বেচ্ছাসেবামূলক হয়, তবে আপনি কতটুকু সময় দিতে পারবেন সে সম্পর্কে সৎ থাকুন। এটা সেই সময়ের সমান নয় যেটা আপনি মনে করছেন প্রকল্পের প্রয়োজন বা অন্যরা আপনার কাছ থেকে যে পরিমান সময় চাচ্ছে।

লিখে রাখার মত কিছু নিয়মকানুন হচ্ছেঃ

  • কিভাবে একটি অবদান পর্যালোচনা(reviewed) এবং গ্রহণ করা হবে (তাদের কি টেষ্ট(test) প্রয়োজন? নাকি ইস্যু টেমপ্লেট(issue template) প্রয়োজন?)
  • কোন ধরনের অবদান আপনি গ্রহন করবেন (আপনার কি কোন নির্দিষ্ট অংশের কোডিং এ সাহায্য প্রয়োজন?)
  • কখন ফলো-আপ করা উপযুক্ত (যেমন, ‘আপনি ৭ দিনের মধ্যে একজন রক্ষণাবেক্ষণকারীর কাছ থেকে প্রতিউত্তর আশা করতে পারেন। যদি এই সময়ের মধ্যে কোন প্রতিউত্তর না পান, তবে থ্রেডটি পিং করতে স্বচ্ছন্দ বোধ করুন(feel free to ping the thread)।)
  • আপনি এই প্রকল্পে কতটুকু সময় ব্যয় করবেন (যেমন, “আমরা এই প্রকল্পে প্রতি সপ্তাহে শুধুমাত্র ৫ ঘন্টা সময় ব্যয় করবো”)

Jekyll, CocoaPods, and Homebrew এগুলো হচ্ছে রক্ষণাবেক্ষণকারী এবং অবদানকারীদের জন্য মৌলিক নিয়ম সহ কিছু প্রকল্পের উদাহরণ।

Keep communication public

Don’t forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.

If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it’s just posting your notes.

That way, anybody who joins your community will have access to the same information as someone who’s been there for years.

Learning to say no

You’ve written things down. Ideally, everybody would read your documentation, but in reality, you’ll have to remind others that this knowledge exists.

Having everything written down, however, helps depersonalize situations when you do need to enforce your rules.

Saying no isn’t fun, but “Your contribution doesn’t match this project’s criteria” feels less personal than “I don’t like your contribution”.

Saying no applies to many situations you’ll come across as a maintainer: feature requests that don’t fit the scope, someone derailing a discussion, doing unnecessary work for others.

Keep the conversation friendly

One of the most important places you’ll practice saying no is on your issue and pull request queue. As a project maintainer, you’ll inevitably receive suggestions that you don’t want to accept.

Maybe the contribution changes your project’s scope or doesn’t match your vision. Maybe the idea is good, but the implementation is poor.

Regardless of the reason, it is possible to tactfully handle contributions that don’t meet your project’s standards.

If you receive a contribution you don’t want to accept, your first reaction might be to ignore it or pretend you didn’t see it. Doing so could hurt the other person’s feelings and even demotivate other potential contributors in your community.

Don’t leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.

It’s better to immediately close the contributions you know you don’t want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for how to triage issues efficiently.

Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it’s someone’s first time. Even if you don’t accept their contribution, acknowledge the person behind it and thank them for their interest. It’s a big compliment!

If you don’t want to accept a contribution:

  • Thank them for their contribution
  • Explain why it doesn’t fit into the scope of the project, and offer clear suggestions for improvement, if you’re able. Be kind, but firm.
  • Link to relevant documentation, if you have it. If you notice repeated requests for things you don’t want to accept, add them into your documentation to avoid repeating yourself.
  • Close the request

You shouldn’t need more than 1-2 sentences to respond. For example, when a user of celery reported a Windows-related error, @berkerpeksag responded with:

Celery screenshot

If the thought of saying no terrifies you, you’re not alone. As @jessfraz put it:

I’ve talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying “No” to patches you don’t want.

Don’t feel guilty about not wanting to accept someone’s contribution. The first rule of open source, according to @shykes: “No is temporary, yes is forever.” While empathizing with another person’s enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.

Ultimately, if a contribution isn’t good enough, you’re under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.

Be proactive

To reduce the volume of unwanted contributions in the first place, explain your project’s process for submitting and accepting contributions in your contributing guide.

If you’re receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:

  • Fill out an issue or PR template/checklist
  • Open an issue before submitting a PR

If they don’t follow your rules, close the issue immediately and point to your documentation.

While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren’t going to accept. And it makes your workload easier to manage.

Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, take steps to defuse the situation or even remove them from your community, if they’re not willing to collaborate constructively.

Embrace mentorship

Maybe someone in your community regularly submits contributions that don’t meet your project’s standards. It can be frustrating for both parties to repeatedly go through rejections.

If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don’t meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked “good first issue,” to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.

Leverage your community

You don’t have to do everything yourself. Your project’s community exists for a reason! Even if you don’t yet have an active contributor community, if you have a lot of users, put them to work.

Share the workload

If you’re looking for others to pitch in, start by asking around.

One way to gain new contributors is to explicitly label issues that are simple enough for beginners to tackle. GitHub will then surface these issues in various places on the platform, increasing their visibility.

When you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish.

Encouraging others to share ownership of the project can greatly reduce your own workload, as @lmccart discovered on her project, p5.js.

If you need to step away from your project, either on hiatus or permanently, there’s no shame in asking someone else to take over for you.

If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It’s great that so many people want your project to live on!

@progrium found that documenting the vision for his project, Dokku, helped those goals live on even after he stepped away from the project:

I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I’d do it? Not always. But it still brought the project closer to what I wrote down.

Let others build the solutions they need

If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.

Forking a project doesn’t have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project’s vision.

The same applies to a user who really wants a solution that you simply don’t have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta found that encouraging plugins for CocoaPods led to “some of the most interesting ideas”:

It’s almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying “no”, but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.

Bring in the robots

Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.

Require tests and other checks to improve the quality of your code

One of the most important ways you can automate your project is by adding tests.

Tests help contributors feel confident that they won’t break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be.

Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You’ll help set a minimum standard of quality for all submissions. Required status checks on GitHub can help ensure no change gets merged without your tests passing.

If you add tests, make sure to explain how they work in your CONTRIBUTING file.

Use tools to automate basic maintenance tasks

The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.

There are a variety of tools available to help automate some aspects of maintenance work. A few examples:

  • semantic-release automates your releases
  • mention-bot mentions potential reviewers for pull requests
  • Danger helps automate code review
  • no-response closes issues where the author hasn’t responded to a request for more information
  • dependabot checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds

For bug reports and other common contributions, GitHub has Issue Templates and Pull Request Templates, which you can create to streamline the communication you receive. @TalAter made a Choose Your Own Adventure guide to help you write your issue and PR templates.

To manage your email notifications, you can set up email filters to organize by priority.

If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.

However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you’re only adding enough rules to make everyone’s lives easier.

If you’re not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.

It’s okay to hit pause

Open source work once brought you joy. Maybe now it’s starting to make you feel avoidant or guilty.

Perhaps you’re feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.

Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.

Although it should go without saying, take a break! You shouldn’t have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take a month-long vacation after 14 years of volunteer OSS work.

Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.

Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.

Do your best to find support for your users and community while you’re away from a project. If you can’t find the support you need, take a break anyway. Be sure to communicate when you’re not available, so people aren’t confused by your lack of responsiveness.

Taking breaks applies to more than just vacations, too. If you don’t want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.

Take care of yourself first!

Maintaining a popular project requires different skills than the earlier stages of growth, but it’s no less rewarding. As a maintainer, you’ll practice leadership and personal skills on a level that few people get to experience. While it’s not always easy to manage, setting clear boundaries and only taking on what you’re comfortable with will help you stay happy, refreshed, and productive.