Hi Stephen, Great idea. ASF infrastructure provides a VM service: http://www.apache.org/dev/services.html#virtual-servers
We could look into this. If this isn't feasible due to licensing or capabilities of what they offer, we could examine hosting something elsewhere. Thanks, Andy On Wed, Mar 9, 2016 at 2:27 PM, Stephen Hauskins <[email protected]> wrote: > I think one missing part is the ability to sell VCL such as online demo > site and clear information about what it can do. > > It seems, at least for me, that is a missing part. You have to be able > to sell the idea to people, the current website is basically > aimed at the developers / installers / administrators. > > If there was a site where one could go and use VCL and be able to fire up > sessions to see what it is like then you can have > a better shot at selling this as a solution to the people who will > probably fund you to get it setup and operational. Plus as I > mentioned before it would be cool to be able to use Docker containers and > have an image repository for non-licenses software, e.g. CentOS with > R/Rstudio . > > I believe it has been mentioned as well, that the actual interface could > use a refresh or major overhaul. > > That's my 2 bits > > > > > Learn about more ITS services in PBSci <http://its.pbsci.ucsc.edu> > > Stephen Hauskins > Purveyor of fine computing services > > 831-334-3961 > > On Wed, Mar 9, 2016 at 10:54 AM, Andy Kurth <[email protected]> wrote: > >> Forwarding this to the user list. Sorry for duplicate copies if you're >> subscribed to both the user and dev lists. I replied to Josh's original >> message which was only sent to the dev list and realized Aaron cross-posted >> the thread after I clicked send. Comments below... >> >> >> ---------- Forwarded message ---------- >> From: Andy Kurth <[email protected]> >> Date: Wed, Mar 9, 2016 at 1:50 PM >> Subject: Re: [DISCUSS] State of Apache VCL >> To: [email protected] >> >> >> >> >> On Mon, Mar 7, 2016 at 3:48 PM, Josh Thompson <[email protected]> >> wrote: >> >>> -----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. >>> >> >> I agree. There have been many good ideas shared which probably deserve >> dedicated threads. However, I'm wondering if it would be better to start >> other threads right now for focused topic discussions, or wait and give >> this thread some more time to work itself out with the goal of keeping >> things organized. I'm afraid of forking an idea off and having similar >> discussion continue to occur in this original thread. Thoughts? >> >> Either way, since there have been so many good ideas shared, I think it >> would be helpful to summarize the ideas on a wiki page. This may help >> ensure we follow up. Any volunteers? This would be an easy way to >> contribute. >> >> >>> >>> > 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. >>> >> >> We have struggled. One way to approach this could be to tie this to #1 >> and set expectations. If you develop something new or change >> functionality, document 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. >>> >> >> Agree. There has been very little collaboration. Again, relates back to >> #1. >> >> >>> >>> 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. >>> >> >> I agree with everything you said. I think #3 and #6 are related. I >> think VCL has been stagnant for a while and needs to be modernized. I >> wouldn't be opposed to exploring big changes. >> >> >>> >>> > 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----- >>> >>> >> >> >
