@Yousaf Nabi (pactflow.io): Wouldn't it be better to leave it open if you'd like people to one day implement it?

for me no, it clogs up my pull request and inbox list, of things raised by me, and if its not going to be actioned, its just noise, No-one has even reacted to the thread, and closing the issue doesn't stop anyone from contributing

Hm. If this is work that the project wants to be done, I reckon it should be tracked somewhere

My view: we should eject this project from the foundation (or we institute a policy that indicates which projects have first class support and those that are "community" supported - I prefer something like this IMO) We need to discuss how we deal with projects that come in with a blaze of excitement and burn out as fast as they appeared. No criticism of anyone here, except our process.

I agree. A good start might be a kind of SLA for pact-foundation projects - like a responsiveness commitment (could be months) on PRs and issues. Not necessarily promising to solve all issues, but at least marking them as "would accept a PR that fixes" or "no, we're not doing this" If an SLA like that were brought in, we could consider it as day zero for all projects

i don’t see the value in reopening that issue

I think it’s a good issue to have open- and I think it’s an easy fix (I’ve considered doing it a couple times)

Then I would re-raise it with the appropriate context with some guide on the work to be done, rather than my random headfart

I wasn’t proposing an SLA to be imposed on the projects, I am proposing an SLA to remain in the pact-foundation. Best applied to new projects on the way in, rather than existing projects in the foundation. But, I also think that it would be reasonable to say “hey, we’ll eject this unless it becomes maintained. Here’s what we mean by maintained <etc>”

how can you SLA an open source project with part time volunteers. hmm

You can’t, really, this is why we are working through the “SmartBear supported” model. We will be able to put some more SLAs around certain items. I’m using the term SLA loosely here - process is probably the better term. What I’d like to see is a model that e.g. tags projects and says “this is community supported, expect XYZ (or expect nothing)” vs “this is tier 1 project, and you can expect us to behave in ABC” way. Then we have a defined model about how issues get in, are triaged and categorised, and then communicated about “what next”. But in reality, time is what people most want to know, and that’s very hard to do with both open / community volunteers, a small team and a large real estate. So I’m very much of the view right now 1. Review all of our assets and scrutinise the value we get - I think we should err on the side of brutal 2. Eject projects from the

pact-foundation

into something like

pact-community

(or archive them as the case may be) that are adding little to no value. Spring Cloud might also fit this bucket, so perhaps it’s the first project we use in the model “it’s not officially supported by Pact or Spring, but we’d like to see XYZ things before it’s moved back to the foundation” (which would include a maintainer that is interested in keeping it alive, a large enough community of users etc. 3. Document and clarify what it means to be an “official” project All of this serves us, yes, but it’s about serving our users - it’s unclear from the outside what is real vs a toy, and therefore what can be trusted.

Maybe

Yep, totally. We need to of course discuss and agree on all those things but I think we’re saying similar things.