-----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-----
