Partly agree. Lighter intake widens the funnel, but friction does not disappear, it migrates. If we relax the template, review has to absorb the slack.
Otherwise we swap visible friction (template) for silent rejection after the work is done. On Jarek's point about getting people "hooked" into Magpie: that hook, in my view, is adoption, not contribution. Contributor and adopter are not the same role. Adopters may become contributors over time, but if an adopter needs an extra skill or agentic tool for their own project, they will likely build it locally in their fork, not push it into our spine. So we should optimise intake for "easy to adopt" (low friction, fork-friendly), and keep upstream review tuned for what actually belongs in the spine. Worth noting: even before the repo is officially published, we are already seeing a contribution surge. I am not against that, the opposite, but review weight will grow fast, especially when the call is "does this skill belong to the whole, or is it specific to one project?", or when we hit overlapping skills proposed in parallel. I think we will need some form of roadmap to steer contributions, otherwise scope judgement is made ad hoc per PR and we will see a lot of overlap. Happy to draft a strawman rubric and a first-pass roadmap if useful. Thanks, André Em qua., 27 de mai. de 2026 às 23:18, Jarek Potiuk <[email protected]> escreveu: > Absolutely agree. > > It was done **really** quickly to begin with - and have **something**. But > I think we should reduce the friction of interacting with Magpie in any way > we can. We need to make it easy for people to get "hooked" into Magpie :) > > On Thu, May 28, 2026 at 4:02 AM Justin Mclean <[email protected]> > wrote: > > > Hi, > > > > I wanted to raise a concern about the current direction of the GitHub > > issue template. > > > > At the moment, it feels a little overly prescriptive about how > > contributors are expected to structure or describe their work. My concern > > is that this may unintentionally narrow the scope of valid workflows or > > discourage people from submitting issues. > > > > Issue templates are useful for ensuring consistency and helping > > contributors provide enough context, but I think we should be careful not > > to make them too rigid or to imply there is only one “correct” way to > > approach a task. > > > > A lighter-touch approach may work better long term. > > > > Thanks, > > Justin >
