Access please, [EMAIL PROTECTED] :) Thanks
On Tue, Oct 21, 2008 at 3:52 PM, Jörn Zaefferer < [EMAIL PROTECTED]> wrote: > Yes, just contact Scott Jehl directly. Either he can handle it, or at > least he knows someone to delegate to. > > I'd like to get access to the planning document! > > Jörn > > On Tue, Oct 21, 2008 at 8:44 PM, Mike Hostetler > <[EMAIL PROTECTED]> wrote: > > Glen- > > > > Thanks for your feedback. I've started a Google Document with this > > information, it's just a skeleton right now. It can be viewed publicly > at: > > http://docs.google.com/Doc?id=dgv8xf4f_54fchbjkc3 > > > > If anyone would like access, please contact me directly. > > > > I currently have plans in my head for how to approach the development of > the > > new site, and how to manage the migration process. I'm not sure how to > > communicate this, other then to just go ahead and do it, after we've > > finalized and agreed to the planning document. My approach reflects my > own > > style and my goal of getting a quality product as fast as possible. I'm > > open to feedback on this. > > > > One area where I know I will need a bit of help is in the graphical > design > > arena. Should I connect with Scott Jehl, the guy who designed the main > > site? I fully plan on using the current Drupal theme, but the individual > > page designs, (CSS and Graphics) are not my best strength. I can > certainly > > tackle them, and leave room for improvement, but I think that the jQuery > > community deserves and expects a certain level of quality here. > Thoughts? > > > > Mike Hostetler > > http://amountaintop.com > > > > > > On Sun, Oct 19, 2008 at 13:47, Glen Lipka <[EMAIL PROTECTED]> wrote: > >> > >> Just a bit of "best practice" for designing a better experience: > >> > >> 1. Create personas. (1-2 hour) These are basically a list of the > >> people who matter and their different "types". > >> Example: New jQuery fan looking for a simple autocomplete. Name: > >> Chuck. What chucks wants: confidence the plugin is a good one. > >> options, comments, etc > >> Example 2: Advanced jQuery plugin author. Name: Sarah. What sarah > >> wants: SVN Access, simple updating, etc > >> There should be around 5 personas or so. (Less than 10) Give them > >> pictures. I swear to god, it makes the whole process easier. > >> > >> 2. Write down use cases (a.k.a. user stories). (2-6 hours) These are > >> REALLY helpful to manage the requirements. If your implementation can > >> achieve these use cases, then you know you didnt forget something > >> like. "Sarah needs to change her password for SVN". > >> > >> 3. Design the user experience in something simple/fast/cheap. I > >> suggest powerpoint, but it could be anything. Just so long as it is > >> the cheapest fastest possible way to show how the thing should be > >> built. > >> > >> 4. Eat your own young. Please don't get hung up on drupal or existing > >> ideas/systems. Redoing something ALWAYS is better than trying to > >> shoehorn an update. Starting from scratch is fun. Go for it! You > >> might end up choosing drupal again, but don't let a bad decision > >> before affect your decisions today. > >> > >> 5. Iterate. It's important to leave room for growth. Wouldn't it be > >> nice for people to vote for a plugin that doesn't exist? or to pay a > >> plugin author money to extend it? ideas are powerful. > >> > >> Anyway, I wish I had more time to devote to jQuery. :( So much > >> powerpoint these days. > >> > >> I'd be happy to help anyway I can. :) > >> Keep "pluggin" away! > >> > >> Glen > >> > >> > >> > >> On Oct 19, 12:27 pm, "Jörn Zaefferer" <[EMAIL PROTECTED]> > >> wrote: > >> > Thanks Rey for sharing ypur AMO experience! > >> > > >> > Afaik doing away with hosting wasn't an option anyway, only project > >> > management doesn't fit the picture. > >> > > >> > You're right that reviewing is a lot of work and requires resources we > >> > probably don't have. A less involved alternative would be to write > >> > down criteria that good plugins should adhere, and just check if those > >> > are met, and if so, highlight the plugin as such. This would cover > >> > aspects that a potential user would usually check before deciding to > >> > use a plugin, like presence and completeness of documentation. > >> > > >> > Jörn > >> > > >> > On Sat, Oct 18, 2008 at 5:31 AM, Rey Bango <[EMAIL PROTECTED]> > wrote: > >> > > >> > > Sorry for jumping so late into this discussion. Thanks for the kudos > >> > > on > >> > > Mozilla AMO Joern. > >> > > >> > > The AMO add-on site is pretty involved. While it looks very simple > on > >> > > the front-end, there's quite a bit going on on the back-end that > helps > >> > > us add, disable, review, approve, diff and version add-ons. > >> > > >> > > While I like some of the ideas being thrown around, I'm not > convinced > >> > > that doing away with hosting is the answer. The fact that we have a > >> > > central place for developers to come to to find plugins is a very > >> > > important advantage to the project. Although there are many plugins > >> > > for > >> > > similar functionality, the fact that we have so many also needs to > be > >> > > viewed as a "positive" as it offers choice to our user base. Having > >> > > lots > >> > > of choices does make things confusing but I'd rather have a little > >> > > confusion than nothing to offer at all. In addition, there have a > >> > > number > >> > > of cases of add-ons that have been seemingly abandoned in the repo > get > >> > > resurrected by a user who needed the functionality and took it over. > >> > > >> > > If anything, I would like to see a combination of both a hosting > >> > > scenario and directory listing. This would allow those developers > that > >> > > wanted to upload their plugin a place to house it while those that > >> > > don't > >> > > can simply point back to their site. > >> > > >> > > I do think, as has been mentioned, that we need to get a better > system > >> > > in place to properly categorize the plugins. On AMO, for example, we > >> > > have multiple categories but we also offer a recommended list of top > >> > > add-ons (about 40 of them) and in addition, for each category, we > >> > > offer > >> > > a list of category recommended add-ons. This has been hugely > >> > > successful > >> > > and in fact, motivates many add-on developers to really improve the > >> > > quality of their work. I can see the same thing being very > beneficial > >> > > to > >> > > the jQuery repo. So going with what Joern said, I think we need to > get > >> > > back to listing our official plugins the way that we used to and > also > >> > > create a recommended list of add-ons that we know are top-notch. > >> > > >> > > In terms of reviewing add-ons, understand that it would be a VERY > big > >> > > task. On AMO, we struggle with that daily because of the number of > >> > > submissions as well as the time involved in reviewing the add-ons. > At > >> > > this point, I'm not sure if we're prepared to take on that task > unless > >> > > we were able to get a good group of volunteers to check the plugins. > >> > > It's definitely a good idea and again, would help the community by > >> > > giving them feedback on improving their work. > >> > > >> > > As for SVN, project management, etc, these are features that are way > >> > > outside of the scope of a plugin repo. This is something that we > >> > > should > >> > > *NOT* do. We don't do this on AMO because of the complexity of this. > >> > > On > >> > > AMO, we host the files necessary to install and add-on and that's > it. > >> > > The developers use other services for managing their project (eg: > >> > > MozDev.org or Google Code). > >> > > >> > > I would say that in order to do this the right way, we would > probably > >> > > need to build our own custom system. At the moment, Drupal doesn't > >> > > seem > >> > > to provide the best way to find plugins and perhaps it's because > it's > >> > > not meant to do so. > >> > > >> > > Rey... > >> > > >> > > Jörn Zaefferer wrote: > >> > >> That sounds very good to me! Releases usually consist of a > download, > >> > >> a > >> > >> version number and a changelog. Thats all the repository should > touch > >> > >> in terms of project hosting - thats also what for example > >> > >> addons.mozilla.com provides. Defining a convention to provide > these > >> > >> via Google Code or a Wordpress blog with minimal effort would free > >> > >> other resources to focus on discussion and promotion of plugins. > >> > > >> > >> Jörn > >> > > >> > >> On Tue, Oct 14, 2008 at 6:17 PM, Diego <[EMAIL PROTECTED]> > wrote: > >> > >>> That would make sense because drupal is very poor and every plugin > >> > >>> I've ever come across has its own homepage hosted elsewhere. Maybe > >> > >>> plugins.jquery.com should focus on being a community for users - > not > >> > >>> developers of jQuery - allowing users to... > >> > >>> - 'watch' their favourite plugins > >> > >>> - discuss/get help from fellow users > >> > >>> - share / rate / comment > >> > >>> - post related links to demos / tutorials > >> > >>> - stay up-to-date with the latest releases > >> > > >> > >>> And the latest releases could be simply based on an XML feed form > >> > >>> the > >> > >>> author's own website - it's probably safe to assume every plugin > >> > >>> developer has one... > >> > > >> > >>> You can't please everyone - so focus on pleasing the users and let > >> > >>> the > >> > >>> developers manage their projects however they're most comfortable > >> > >>> with... > >> > > >> > >>> How about that? > >> > > >> > >>> Cheers, > >> > >>> Diego A. > >> > > >> > >>> On Oct 14, 4:00 pm, "Nathan Bubna" <[EMAIL PROTECTED]> wrote: > >> > >>>> +1 get out of the plugin project hosting business. make the > plugin > >> > >>>> site a way to list/find/promote plugins, not a place to manage > >> > >>>> them. > >> > > >> > >>>> On Tue, Oct 14, 2008 at 2:34 AM, Diego A. <[EMAIL PROTECTED]> > >> > >>>> wrote: > >> > >>>>> Hi guys, > >> > >>>>> I agree with all the points raised by Yehuda and Jorn, but > >> > >>>>> unfortunately > >> > >>>>> Mike, the biggest problem of all is Drupal. > >> > >>>>> In a nutshell :- > >> > >>>>> - The navigation is shocking > >> > >>>>> - Issue management is long winded and painfully time-consuming > >> > >>>>> - So is uploading new files / creating new releases > >> > >>>>> I feel Yehuda and Jorn's points are great, but they focus > >> > >>>>> primarily around > >> > >>>>> giving jQuery user's better access to plugin - which is > undeniably > >> > >>>>> a > >> > >>>>> must-have great idea. However, The system must also cater for > >> > >>>>> those who do > >> > >>>>> (and will) voluntarily maintain their projects within the > >> > >>>>> community. > >> > >>>>> With that in mind, I recently moved all my plugins to Google > code > >> > >>>>> for the > >> > >>>>> following reasons :- > >> > >>>>> - Sub-version access > >> > >>>>> - Easy navigation > >> > >>>>> - Easy-to-use issue management system (with configurable email > >> > >>>>> alerts) > >> > >>>>> - WIKI (for project documentation) > >> > >>>>> - Ability for project collaboration > >> > >>>>> Hope that helps in some way... > >> > >>>>> Cheers, > >> > >>>>> Diego A. > >> > >>>>> 2008/10/13 Mike Hostetler <[EMAIL PROTECTED]> > >> > >>>>>> Hi Everyone- > >> > >>>>>> I'd like to start a discussion on how we can improve the > plugins > >> > >>>>>> repository to better fulfill the needs of the community. When > we > >> > >>>>>> first created the plugins site, there were a lot less plugins. > >> > >>>>>> As > >> > >>>>>> jQuery's popularity continues to rise, the need for additional > >> > >>>>>> features for plugin authors is growing. > >> > >>>>>> As the person most familiar with the plugins site, I get a > decent > >> > >>>>>> amount of requests for tweaks here and there. Unfortunately, > >> > >>>>>> because > >> > >>>>>> of the choice of using Drupal with Drupal's Project module, the > >> > >>>>>> amount > >> > >>>>>> of features that can be easily turned on is small. I've been > >> > >>>>>> very > >> > >>>>>> cautious at modifying the source code of the Project module for > >> > >>>>>> many > >> > >>>>>> reasons. I'm in touch with the leaders of the Project Module, > >> > >>>>>> having > >> > >>>>>> met up with them at the last Drupalcon. Currently, there is > >> > >>>>>> ongoing > >> > >>>>>> work on the Project module for Drupal.org, and the Project > module > >> > >>>>>> remains the last major issue in upgrading Drupal.org to Drupal > 6. > >> > >>>>>> So, > >> > >>>>>> this problem is bigger then jQuery. > >> > >>>>>> What I'd like to solicit is feedback on the following: > >> > >>>>>> - What works with the current plugins site, what are it's > >> > >>>>>> strengths? > >> > >>>>>> - What doesn't work, where does it fall down? > >> > >>>>>> - What are the top 5 major features missing from the current > >> > >>>>>> site? > >> > >>>>>> - Are there any other open source project management solutions > >> > >>>>>> that > >> > >>>>>> are worthy of consideration to replace Drupal and the Project > >> > >>>>>> module? > >> > >>>>>> (PS. Because of the work involved in this, I would consider > this > >> > >>>>>> only > >> > >>>>>> as a last resort) > >> > >>>>>> - Any other feedback is appreciated > >> > >>>>>> Thanks, > >> > >>>>>> Mike Hostetler > >> > >>>>> -- > >> > >>>>> Cheers, > >> > >>>>> Diego A. > >> > > >> > > >> > >> > > > > > > > > > > > > > -- Ariel Flesler http://flesler.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
