-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks - Please speak up in this thread! If you are hesitant to because you think your comments may be too critical, we would rather hear them and be able to improve the health of the project rather than not hear them and let it continue to degrade in health.
On Thursday, March 03, 2016 11:02:19 AM Andy Kurth wrote: > Hello Apache VCL dev community, > Back in December, I started a thread for the discussion of that month's > board report. In that thread, I brought up concerns I had regarding the > state of the development community's health. Please review the thread: > http://markmail.org/message/3oz7rhy5fyv57nxt > > Please also review the board report that was submitted: > https://cwiki.apache.org/confluence/display/VCL/2015-12-16+Apache+VCL+Board+ > Report > > We have another board report coming up in March. There is a tool > that project chairs use to help prepare the report which gathers some > information and comes up with a project "health score". For Apache VCL, it > > displays the following: > > Apache VCL: Unhealthy > > Health score: -0.20 > > Score note: Less than one email per day to all MLs combined in the past > > quarter (-1.00) > > Score note: No new members added to the LDAP committee group for more than > > 2 years (-2.00) > > Score note: No new committers invited for more than a year (-1.00) If our reports keep looking like the above, we'll definitely be getting the board's attention. > There are several indicators one could consider to gauge health of a > project. List traffic is one. If you look at the graph at > http://vcl.markmail.org/, you can see traffic has been markedly lower in > recent months. This includes messages sent to the user, dev, and commits > lists. If looks even worse if you look at user list traffic alone: > http://vcl.markmail.org/search/?q=list%3Auser > > Another indicator is whether or not the number of committers and PMC > members increases. This has proven to be difficult for VCL. As I think > Josh correctly pointed out in the thread referenced above, the nature of > VCL and its predominant audience (higher ed) may be factors which have made > it difficult to attract new developers who make consistent contributions. > I personally do not feel that regularly increasing the number of committers > says a whole lot about the health of the project. A project can very > healthy with a stable and small number of committers as long as they are > regularly contributing. That said, the last time we added a committer was > over 2 years ago and I don't know of any prospects. Regardless of how > heavily you weight this indicator, it doesn't look good. > > In the past, some have approached these issues by thinking "hey, let's just > try to find some more committers." This hasn't worked. We need a new and > better approach if this project is to remain viable. We could start by > working on areas we have direct control over and improving the ancillary > details related to the project. Below are some ideas I can think of: > > 1. Increase involvement from existing committers > In the thread from December, I was hoping to gauge people's concern and > elicit thoughts and ideas from others. Unfortunately, only two people > responded and no ideas were shared regarding how to improve the community. > > Based on the counts from Subversion and http://vcl.markmail.org/, here is > the total number of messages sent and commits made from the project's > current committers from 1/1/2015 until last week (I started typing this up > a while ago): > > Comitter Messages Message Percent Commits Commit Percent > Josh Thompson 542 49% 129 46% > Andy Kurth 414 38% 124 44% > Aaron Peeler 107 10% 18 6% > Aaron Coburn 14 1% 0 0% > Dmitri Chebotarov 14 1% 4 1% > Young-Hyun Oh 7 1% 4 1% > James O'Dell 0 0% 0 0% > David Hutchins 0 0% 0 0% > > There are some threads such as this one and release discussions that I feel > all committers should participate in. By participate, I mean more than > simply replying "+1" or "good point, I agree". > > Increasing participation from committers may also have a snowball effect > for others lurking on the lists and new subscribers. People may be more > inclined to participate if the threads if they appear to be a more of a > community discussion (which they all are) rather two people communicating > back and forth. > > I think we need to come to an understanding regarding what is expected of > committers. We also need to figure out how to address situations where > committers are not participating. Coming up with what we (the VCL community) should expect of committers would be a good start. We should hash that out in a separate thread and then write up the results on a page under the Community section of the website. Some initial ideas that should go in that thread are coding, documentation, and list involvement. > 2. Documentation > Before someone could ever make development contributions to the project, > they would need to be able to install VCL and have a good understanding of > it. This isn't easy because the documentation is poor. If someone does > gain a solid understanding of administering VCL and could potentially > contribute back, our development documentation doesn't provide much > information about where to get started or about the inner workings. > Improving our documentation will help increase the adoption of VCL and also > make it easier for people to contribute. We've always struggled with documentation. There are a number of reasons for that - we're coders, not writers; little time to do it; expectation of others creating docs; lack of understanding by others to be able to create docs - but as you pointed out, people aren't going to get involved if they don't understand how. We need to expand the "Getting Involved" part of our website to have a clear guide on getting involved with development. This needs to include a roadmap, clear explanation of how to work on JIRA issues, and clear documentation about the code structure and how someone would start developing on it. > 3. Vision & Roadmap > In order to get voluntary development contributions, a project has to be > appealing to developers. In order to be appealing, they have to know where > it's going. Wherever that is, it needs to be interesting and useful. We > don't have much of a roadmap or a vision of how VCL will look in the > future. We should define and communicate a roadmap and vision. This is another area we've alway struggled with. I think part of that is the fault of the committers in not doing a better job of seeking out what the community of VCL users would like to see in VCL. I also think part of it is how slow we are to get releases out. They don't come out fast enough for people to really be able to look forward to new features being added. 4. Lack of development transparency I think this is another thing that's caused problems with involvement. Those of use who are committers haven't done a good job of discussing what we are working on and seeking feedback on it. Personally, I know this is a problem for me mainly because of the time it takes to write up what I'm doing. 5. User list discussions I don't know why people that use VCL seem to be somewhat silent on our list. Maybe we need to include something on our download page that just asks people to ping the list when they download and set up VCL just so we know that people are really using it. Doing web searches of VCL shows a number of places using it from which I don't remember ever hearing anything. It's an open source project. So, that's fine if people don't want to say they're using it, but it would be helpful and give us a better understanding of how useful the project really is. 6. Language and Architecture VCL is written in PHP (with some javascript) and perl. The frontend utilizes an old architecture of web development where the UI is largely generated server side. PHP, perl, and the current frontend architecture are older and less popular now. I'm not suggesting we change things now (nor do we have the development time to do so), but it may be a contributing factor as to why we aren't picking up more committers now. > Starting with these points and hopefully others share more ideas, we may be > able to make the project more appealing and improve its health. I'm not > willing to do this alone, and it wouldn't be in accordance with "the Apache > way" for Josh Thompson and I to do this alone. We both work for the same > organization and organizational diversity is something we need to consider > as well. If there simply isn't interest by others in sharing ideas and > contributing, that's fine. However, if that's the case we will need to > have a frank discussion about the future of the project and its > relationship with Apache. > > Thank You, > Andy Andy - Thanks for starting this thread. It is a tough discussion to really analyze how we are doing as a project, which largely reflects on us as committers, but we're definitely to a point where we need to have the discussion. Josh - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlbd6SwACgkQV/LQcNdtPQOl9wCeIRlktxeLX1i4nLE9Iz3/F0AP z7UAn3clkULJYkKBLWBRlaae5aGRI/Ep =MSg5 -----END PGP SIGNATURE-----
