I've added a few things for your consideration for this process, specifically types of projects and what inactivity means.
Hi @jim, Thank you for your feedback!
We've actually been discussing a definition for inactivity, as it was not clearly defined in the original policy. The idea in the originator's brain was to clean up test projects and other "nonsense" or "empty" projects that clutter up so many open communities.
Our Technical Advisory Group facilitator, @tomg2012 , was kind enough to create a merge request with some suggested language in it and also added some clarity on different types of projects. Your feedback on these suggestions would be greatly appreciated either here asynchronously or at the Community Advisory Group's next meeting, if you are available on May 11th at noon Eastern US time. A clean copy of the policy with the changes incorporated is also available for review.
Best Regards, ~Beth
Beth Hancock (b34e46e1) at 10 May 13:52
Update README.md
Your current policy is not very practical for real projects. Commercial vendors in the EDA (electronic design automation) space do releases about once every 6 months. I don't think open source projects should be held to that metric.
When an open source project is mature, the period between updates may be longer than 6 months. It may also be influenced by other factors - such as work load of the individuals working on the project. However, the project is still valuable to the community.
Maybe a better metric would be a check for any project activity - an update should be counted as one form of activity, but so should responding to any open issues or pull requests (that were not previously responded to). Note if there are no issues or pull requests, maybe a project is mature and is being maintained at a slower pace - which is ok. Note I do not necessarily think it should be respond to all issues and pull requests. We are checking to see if they are doing anything. Also note I think it should be respond to and not necessarily address as an issue want to take a project in different direction than it is currently planned.
For example, think of a test results reporter for Continuous Integration - if all the features are working and there are no issues or pull requests, then no activity is still ok. It would be a disservice to the community to move or archive the project as if an issue were encountered then how would we report an issue.
I also think we are in exceptional times. For me they are working in favor of open source project updates as I am meeting on-line rather than traveling. So right now, I have more time to spend on my project and am doing frequent updates. OTOH, when we open, it is likely that I will be traveling alot and updates are likely to be less frequent.
Hi @tomg2012! Thank you for tackling this! I see a lot of value in your suggestions and will take these to the CAG and request feedback on them. I am not sure what will be happening this coming meeting, as it is Evan's first as facilitator. I need to reach out to him and see what he wants to address. I will keep you updated!
Many thanks! ~Beth
I've added a few things for your consideration for this process, specifically types of projects and what inactivity means.
Thomas Gilmour (5f0c84fc) at 18 Apr 19:50
I've added a few things for your consideration for this process, sp...
Beth Hancock (472269fe) at 16 Feb 22:04
Update README.md - Updated with feedback from 2022 02 16 CG meeting.
Beth Hancock (9ddf97bd) at 15 Feb 22:41
Update README.md Draft
Beth Hancock (18cdb661) at 29 Sep 17:24
Update README.md
Beth Hancock (d1a2a5fb) at 29 Jul 20:41
Update README.md
Beth Hancock (87d6983a) at 29 Jul 20:40
Initial commit