Dear @akent99 Thank you kindly for responding.
I don't think I just speak for myself when I say that I think that the lack of transparency/visibility is what is currently the biggest issue most Mag2 adopters have (be they developers or site builders)? I'd go so far to say it could realistically kill Mag2 in the real world before it manages to realise it's true awesome potential! But that may be just frustration talking?
We all understand this is free open source software and that EE comes first and makes CE possible. There are constantly going to be bugs to fix and everybody will have their own personal opinion about priority and we all appreciate that you simply can't please all of the people all of the time. However; when adopters are adhering to the appropriate/chosen methods of contact (github issue queues & these forums), I think we have a right to expect open and honest communication. Unfortunately, and as you've already (graciously!) alluded to, sadly that's not really what most of us (the CE community/adopters) are currently experiencing.
So; I hope that this post, or the parts of post that nobody wants to answer openly, won't fall on deaf ears as is evidently typical (to date)! We, the community, really do need the full and willing co-operation of the Mag2 team or a representative(s) of the team so that the community can survive. And you, the Mag2 team, actually need adopters of your software whether you realise this or not?
So, I truly hope that you can and will spare the time (precious as it undoubtedly is) to respond with answers or suggestions even which might help resolve the following scenarios:
- when bugs exist; adopters(agencies/developers etc) need some way to communicate with clients or potential clients to advise when a bug will be fixed (not might - will!)
- And/or they need a documented best practise approach to attempt fixing these bugs themselves, e.g. preferably to follow the exact same practices as the core Mag2 team.
My simplified view on these predicaments is this:
- you identify fixed/acknowledged bugs that will be included on a specific stable release and you also provide some indication of progress towards said stable releases so that the rest of the world has some hope of working out when the fixed bugs might be available? Wouldn't it be great if we all had live visibility (even if, as is likely, some issues slip the net) but for now just some transparency. Perhaps you could give issues an additional status after 'fixed' to identify an intention/confirmation to merge into a specific release, e.g. (v2.X.x - for definitely going in this release | v2.X.x/x+1 for next or following release | etc?). Then of course you're going to have to hint at stable release dates! e.g. https://www.drupal.org/core/release-cycle-overview
- Additionally please will you make available or document the script or process used by Mag2 team when 'publishing' develop branch core modules to merge back into a stable release. This will allow developers a) to follow what 's been adopted as best practice by the mag2 team, and b) to pull fixes from the develop branch and merge into their own stable sites using what I assume will be the most appropriate procedure. Additionally this will allow community developers to offer/provide their own fixes back to the mag2 team or indeed to the mag2 community in either format/structure, e.g. to be merged back into the develop branch (mag2 team) or as a patch for the community.
I very much look forward to your reponse.
