I tried to write some inspirational words, but decided that while I might find them inspirational, they were probably just a waste of time.
So rather than a call to action, I'm just going to throw out a short list of todos, that I'm hoping people will add to and expand upon. These are in no particular order.
1. New uploads to JSAN aren't being acknowledged in a timely manner. This got left off my initial list, but Dave Rolsky mentioned it, and I have to agree that it is a huge problem. If someone takes the time to do something the JSAN way, and upload it, only to have it disappear, they will become frustrated, and we will lose yet another potential user. If this is simply a matter of a getting a new master up and running, I have temporary space I can lend until the project regains momentum, and we need to find a real home.
2. The JSAN Client. We need to make sure it's packaged up for major distributions. We need to make sure it's easily accessible by non perl people. They don't need to know it's a perl script. It's just the JSAN client. You get it and use it like any other app. Personally I like it being perl, but CPAN shouldn't be the first place a person thinks to look for it.
3. The website, needs to be improved for its target audience. The way I see it, there are 2 or 3 roles users will fall into for the site. Developers looking to upload to JSAN, developers looking to use code from JSAN, and perhaps some misc 3rd I'm leaving out. If I go to the site, there should be a simple way to accomplish any of the major roles, right from the first page. We need better organization, and dare I say it, market appeal.
4. JSAN needs a bundler for end users. If I'm an end user, and I'm using 10 libraries from JSAN, I should be able to bundle them all together automatically, to create my own personal bundle, that can be loaded and used in my webapp, without 10 separate calls to load separate js files. This is a major problem that some major JS libraries are already starting to address. Dojo I believe has something very similar to this. The JSAN client should have functionality to address this.
5. We need to support those without a command line, or those with less of one, or simply those that don't use it. JS developers, whether they're designing large libraries or small 1 off hacks, should be able to do everything required to get their code into JSAN, via the website. Have 20 lines of js you want to publish as the doohicker function? copy, paste submit, fill out a quick form, perhaps we can even auto suggest names, author values, and all that fluff based on parts of what they paste in. We can put it in a proper jsan package, which in turn, they can download. Now not only did we make their life easier, but we've just set them up with their code in a package, that perhaps they will continue to maintain in that format.
6. Distributions need to be browseable. The tag cloud is cool, the searching is ok, but I just want to walk through the distros, and I can't from the site.
7. Get things moving. Just having a list of things that need to be done in my opinion is huge, because there's a lot to do. But we have some other hurdles. Even after code gets checked in, who's checking it out, and putting it into production? That's as much of a hurdle as code contributor's packages not showing up on the site. Who wants to hack on code that doesn't get deployed? Where's it deploying? Is the master in shambles? Can we just move it anywhere and be done with it? Let's just take the step. Frankly at this point, how many people will be hurt if the infrastructure of JSAN goes down for 5 mins, or even a day? We need desperately to get changes to the project out and in production, so people see us making progress, so that they see life in the project. Just changing the front page and putting the word FOO at the very top would be better than what we have now. We've lost the attention of major js libraries who initially put for the effort, because they see us as stagnant or have been told as much, but I know they're still interested.
And on a final note, join us in #jsan on freenode. A few of us are still there trying to keep the discussion moving forward.
John Cappiello wrote: > 3. The website, needs to be improved for its target audience. The way I > see it, there are 2 or 3 roles users will fall into for the site. > Developers looking to upload to JSAN, developers looking to use code > from JSAN, and perhaps some misc 3rd I'm leaving out. If I go to the > site, there should be a simple way to accomplish any of the major roles, > right from the first page. We need better organization, and dare I say > it, market appeal.
Whether the browsing is done by tag cloud, by category, or whatever, it seemed to me that it would be best to optimize the interface for finding code first, based on the old DBA mantra that you'll always have more reads than writes.
I've stripped down the navigation links to three top level links
- what is this place - how can i contribute/get involved - i'm a contributor, let me log in to JAUSE
I think all of the documentation, FAQ and so forth should be pushed out to the Wiki. The 'get involved' and 'about JSAN' links would be links into the wiki. From there they could navigate to other places:
Get Involved - mail list - irc - JAUSE signup - subversion - etc
John Cappiello wrote: > I tried to write some inspirational words, but decided that while I > might find them inspirational, they were probably just a waste of time.
> So rather than a call to action, I'm just going to throw out a short > list of todos, that I'm hoping people will add to and expand upon. > These are in no particular order.
> 1. New uploads to JSAN aren't being acknowledged in a timely manner. > This got left off my initial list, but Dave Rolsky mentioned it, and I > have to agree that it is a huge problem. If someone takes the time to > do something the JSAN way, and upload it, only to have it disappear, > they will become frustrated, and we will lose yet another potential > user. If this is simply a matter of a getting a new master up and > running, I have temporary space I can lend until the project regains > momentum, and we need to find a real home.
> 2. The JSAN Client. We need to make sure it's packaged up for major > distributions. We need to make sure it's easily accessible by non perl > people. They don't need to know it's a perl script. It's just the JSAN > client. You get it and use it like any other app. Personally I like it > being perl, but CPAN shouldn't be the first place a person thinks to > look for it.
> 3. The website, needs to be improved for its target audience. The way I > see it, there are 2 or 3 roles users will fall into for the site. > Developers looking to upload to JSAN, developers looking to use code > from JSAN, and perhaps some misc 3rd I'm leaving out. If I go to the > site, there should be a simple way to accomplish any of the major roles, > right from the first page. We need better organization, and dare I say > it, market appeal.
> 4. JSAN needs a bundler for end users. If I'm an end user, and I'm > using 10 libraries from JSAN, I should be able to bundle them all > together automatically, to create my own personal bundle, that can be > loaded and used in my webapp, without 10 separate calls to load separate > js files. This is a major problem that some major JS libraries are > already starting to address. Dojo I believe has something very similar > to this. The JSAN client should have functionality to address this.
> 5. We need to support those without a command line, or those with less > of one, or simply those that don't use it. JS developers, whether > they're designing large libraries or small 1 off hacks, should be able > to do everything required to get their code into JSAN, via the website. > Have 20 lines of js you want to publish as the doohicker function? > copy, paste submit, fill out a quick form, perhaps we can even auto > suggest names, author values, and all that fluff based on parts of what > they paste in. We can put it in a proper jsan package, which in turn, > they can download. Now not only did we make their life easier, but > we've just set them up with their code in a package, that perhaps they > will continue to maintain in that format.
> 6. Distributions need to be browseable. The tag cloud is cool, the > searching is ok, but I just want to walk through the distros, and I > can't from the site.
> 7. Get things moving. Just having a list of things that need to be done > in my opinion is huge, because there's a lot to do. But we have some > other hurdles. Even after code gets checked in, who's checking it out, > and putting it into production? That's as much of a hurdle as code > contributor's packages not showing up on the site. Who wants to hack on > code that doesn't get deployed? Where's it deploying? Is the master in > shambles? Can we just move it anywhere and be done with it? Let's just > take the step. Frankly at this point, how many people will be hurt if > the infrastructure of JSAN goes down for 5 mins, or even a day? We need > desperately to get changes to the project out and in production, so > people see us making progress, so that they see life in the project. > Just changing the front page and putting the word FOO at the very top > would be better than what we have now. We've lost the attention of > major js libraries who initially put for the effort, because they see us > as stagnant or have been told as much, but I know they're still > interested.
> And on a final note, join us in #jsan on freenode. A few of us are > still there trying to keep the discussion moving forward.
