Milestone 13 Incorporating Feedback From Non-Git/GitHub Users

Hey guys! Ever faced the challenge of getting feedback from someone who isn't familiar with Git or GitHub? It's a common scenario, especially in collaborative projects. This article will walk you through Milestone 13, focusing on how to effectively incorporate feedback from individuals who might not be using Git/GitHub. Remember, science should be inclusive and not overly reliant on specific tools. Let’s dive in!

Task Incorporating Feedback from Less-Than-Ideal Sources

Sometimes, feedback comes in forms that aren't exactly Git-friendly – handwritten notes, marked-up printouts, you name it. The key is to not let the format hinder the valuable input. Your main objective here is to bridge the gap between different methods of providing feedback and your Git-based workflow.

Why This Matters: The Importance of Inclusivity

It's crucial to acknowledge that not everyone has the time, energy, knowledge, or capacity to use Git and GitHub. That's perfectly okay! Imposing tool-specific requirements can unintentionally exclude valuable contributors. We want scientific collaboration to be accessible to everyone, regardless of their tech skills. Embracing diverse input methods ensures a more comprehensive and inclusive process, ultimately leading to better research outcomes. By accommodating various feedback formats, you tap into a wider pool of expertise and perspectives, enriching your project and fostering a truly collaborative environment. Remember, the goal is to make the process as seamless and inclusive as possible, ensuring everyone feels welcome to contribute their insights.

Detailed Steps: A Practical Guide to Handling Non-Git Feedback

Let's break down the process into manageable steps. We'll use a scenario where "Prof. Grumpy" has provided handwritten notes on a printed version of a preregistration document. Don't worry, we'll turn those notes into actionable changes!

Step 1: Look at the Feedback - Deciphering the Notes

The first step is to carefully review the feedback. Imagine Prof. Grumpy handed you a stack of papers covered in handwritten notes. Your task is to decipher these notes and understand the suggestions. This might involve:

• Reading through the comments multiple times.
• Identifying the specific sections of the document being referenced.
• Trying to understand the underlying rationale behind each comment.

In our example, we have images of Prof. Grumpy's notes. Take your time to go through each note and understand the feedback being provided. This initial assessment is crucial for the next steps.

Step 2: Decide What's Ready for Implementation and What Needs More Work - Prioritizing and Planning

Once you've reviewed the feedback, it's time to strategize. Not all feedback is created equal – some suggestions might be straightforward to implement, while others might require further discussion or a more substantial overhaul. This step involves triaging the feedback and deciding on the best course of action for each item.

1. Find the things you can/want to change right away: Identify the comments that are clear, actionable, and align with your project goals. These are the low-hanging fruit – changes you can implement quickly and easily.
2. Change them in a branch, open a PR, let your partner review: For these immediate changes, create a new branch in your Git repository, implement the changes, and then open a Pull Request (PR). This allows your collaborators to review the changes before they're merged into the main branch. This step is crucial for maintaining code quality and ensuring everyone is on the same page. By creating a separate branch, you isolate your changes, preventing any disruption to the main codebase. The Pull Request then serves as a formal proposal for incorporating your modifications, triggering a review process that involves your team members. This collaborative approach not only helps catch potential errors but also fosters a shared understanding of the project's evolution.
3. Bigger things could perhaps use an issue, for discussion and assignment: Some feedback might be more complex or require significant changes. For these items, create an issue in your issue tracker (e.g., GitHub Issues). This provides a dedicated space for discussion, clarification, and task assignment. For example, Prof. Grumpy's suggestion of implementing the "21-word solution" might require a more in-depth discussion before implementation.
4. After that rinse and repeat 2: Once you've addressed the larger issues, revisit step 2 to implement the changes in a branch, open a PR, and get your partner's review. This iterative process ensures that feedback is incorporated systematically and collaboratively. This iterative cycle of implementation, review, and refinement is at the heart of agile development practices, allowing for continuous improvement and adaptation throughout the project lifecycle. By embracing this approach, you can ensure that your project remains responsive to feedback and evolves in a way that meets the needs of all stakeholders.

Expected Results: Tangible Outcomes

The expected outcome of this milestone is to have one or more Pull Requests (PRs) that reflect Prof. Grumpy's comments. This demonstrates that you've actively engaged with the feedback and are taking steps to incorporate it into the project. The PRs serve as a tangible record of the changes made and provide a clear audit trail of the feedback process. This transparency is crucial for maintaining accountability and ensuring that all contributions are properly acknowledged.

Discussion: When to Track People in Git

This raises an interesting question: When does it make sense to track other people directly in Git, and when is it better to accommodate external feedback methods? There's no one-size-fits-all answer, but here are some things to consider:

• Git proficiency: If someone is comfortable with Git, involving them directly in the workflow can streamline collaboration. They can create branches, submit pull requests, and participate in code reviews.
• Contribution frequency: For frequent contributors, Git integration can be highly efficient. However, for occasional feedback providers, alternative methods might be more appropriate.
• Project scope: Smaller projects might benefit from direct Git involvement, while larger projects might need a more structured approach to managing external feedback.
• Tool preferences: Respect individual preferences. Forcing someone to use a tool they're uncomfortable with can be counterproductive.

Ultimately, the goal is to find a balance between leveraging Git's capabilities and accommodating diverse feedback styles. The key is to remain flexible and adapt your approach based on the specific needs of your project and collaborators. By striking the right balance, you can ensure that everyone feels empowered to contribute their expertise, regardless of their technical background.

When Done: Marking Completion

Once you've addressed Prof. Grumpy's comments and created the necessary PRs, comment /done 13 in the tracking issue to mark this milestone as complete. This helps keep the project organized and ensures that all tasks are properly tracked.

Conclusion: Embracing Inclusive Collaboration

Incorporating feedback from individuals who don't use Git/GitHub is a crucial aspect of inclusive collaboration. By embracing diverse input methods and adapting our workflows, we can create a more welcoming and productive environment for everyone. Remember, the goal is to value the feedback itself, regardless of how it's delivered. So, next time you receive handwritten notes or marked-up printouts, don't fret – embrace the challenge and turn that feedback into valuable improvements for your project! You've got this, guys!