Re: Fedora Community

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If I can just toss in my 2 cents:  I joined up on this when I thought  
I was going to contribute as a build/release manager for Fedora.  I  
wound up going the Ambassador route instead, but I think the tool is  
great and I'd love to see it mature.  I still plan on doing release  
management down the road and from what I see right now, this would be  
a great default homepage for status on those activities.  Also, it's  
quite useful in planning a Fedora Remix to search out packages,  
maintainers and versions despite the browser interface overhead :)

I personally vote (unofficially, of course) to enhance and release it.

Cheers,

Christian Bryant | Los Angeles, CA

http://fedoraproject.org/wiki/User:christianabryant
http://wiki.laptop.org/go/User:christianabryant
http://www.linux.com/community/blogs/blogger/christianabryant/
http://identi.ca/christianabryant

4096R/418C1BBA 39B5 C0D0 D57F 5FC9 11C8  7A01 8B2F 0A9F 418C 1BBA


----- Message from smooge@xxxxxxxxx ---------
     Date: Wed, 6 Jul 2011 17:34:46 -0600
     From: Stephen John Smoogen <smooge@xxxxxxxxx>
  Subject: Re: Fedora Community
       To: Fedora Infrastructure <infrastructure@xxxxxxxxxxxxxxxxxxxxxxx>
       Cc: spot@xxxxxxxxxxxxxxxxx, websites  
<websites@xxxxxxxxxxxxxxxxxxxxxxx>, duffy@xxxxxxxxxx


> On Wed, Jul 6, 2011 at 15:53, Luke Macken <lmacken@xxxxxxxxxx> wrote:
>> Excerpts from Stephen John Smoogen's message of Tue Jul 05 17:44:46  
>> -0400 2011:
>>> No not http://fedoracommunity.org but
>>> https://admin.fedoraproject.org/community/ It has been in beta for 2
>>> years now. What do we need to do to finish it (maybe make it
>>> start.fedoraproject.org?) or put it aside for other things to do?
>>
>> This app was never really intended to ever be "finished". It was meant
>> to be a platform for building widgets to visualize Fedora data. However,
>> I do think it's definitely still 'beta' quality, and the original
>> authors (J5, Mo, and I), have not had the cycles to continue to improve
>> it. We accomplished our initial goals, and then got pulled into
>> different directions (one of which was working on the core of the
>> platform, Moksha).
>>
>> Personally, I still use fedoracommunity on a regular basis, and find it
>> to be extremely useful in many ways. Right now we do not have any idea
>> as to how many people are using it. I think we should do some log
>
> Did the following quick statistics using awk:
>
> Currently we are seeing 380->420 unique ip addresses per month who are
> not bots or not referrals from other sites. Most go to /community/ but
> ~100 of them made queries beyond standard page data (images,
> javascript, and /community/). While it doesn't sound a lot.. for a
> site that doesn't have a lot of advertising it is an audience.
>
>> analysis, and maybe a survey to see what people like/dislike/want. Also,
>> Mo did a usability study at FUDCon many moons ago, and we have yet to
>> really sit down and analyze the results.
>>
>> So, in order to remove the 'beta' from fedoracommunity, I would
>> personally like the see the following happen:
>>
>> &nbsp; &nbsp;* Polish up the interface, and make it *much* snappier.
>> &nbsp; &nbsp; &nbsp;Right now the interface feels very clunky, and  
>> the full page
>> &nbsp; &nbsp; &nbsp;reloads when clicking on certain areas is  
>> killing us. There
>> &nbsp; &nbsp; &nbsp;is still a lot of low-hanging fruit in terms of  
>> optimization.
>>
>> &nbsp; &nbsp;* Re-branding, marketing, and a better URL.
>> &nbsp; &nbsp; &nbsp;"Fedora Community" has become an overloaded  
>> term, and has since been
>> &nbsp; &nbsp; &nbsp;associated with the language-specific  
>> subcommunity portals. We also
>> &nbsp; &nbsp; &nbsp;don't link to the app from anywhere, and the  
>> URL is not the
>> &nbsp; &nbsp; &nbsp;easiest to remember.
>>
>> &nbsp; &nbsp;* Documentation.
>> &nbsp; &nbsp; &nbsp;Right now there is no documentation that guides  
>> people through
>> &nbsp; &nbsp; &nbsp;building a new app/widget using our  
>> infrastructure's APIs.
>> &nbsp; &nbsp; &nbsp;Copying/pasting existing code has made  
>> contributing painful.
>>
>> With regard to the claims that the AGPL makes this app difficult to
>> maintain -- I honestly cannot recall a single case where we had to
>> hotfix it and jump through the AGPL hoops. If anything, this helped us
>> figure out what it takes to develop, deploy, and maintain both
>> TurboGears2 and AGPL applications.
>
> We did it twice right after it was deployed. We went one way in how we
> were going to do this and had to undo it the next day when Tom got
> clarification that pointing to tickets/patches was not acceptable. If
> we could move to Apache or just GPL I would be quite happy. My memory
> of it was that there was a bunch of stuff having to be done right
> then, but it is a memory and probably not a good one.
>
> My main concern has been about having something that was having code
> rot because other priorities had taken the programmers away. We have
> had to do some soul searching on services we offer and if the code was
> not going to get much development time was it something infrastructure
> could keep up (eg like blogs, asterisk, etc)
>
>> Spot, J5 and I will be meeting next Thursday to draft a potential
>> roadmap going forward.
>>
>> Personally, I envision the following improvements and additions (as I
>> mentioned at the last FUDCon):
>>
>> &nbsp; &nbsp;* Mailing list interface (a decent amount of code  
>> already written)
>> &nbsp; &nbsp;* Meeting app, to visualize our meetbot output (some  
>> code written)
>> &nbsp; &nbsp;* SIG dashboards, with action items, SOPs, packages,  
>> people, meetings, etc
>> &nbsp; &nbsp;* Package review app
>> &nbsp; &nbsp;* Improved upstream integration & adoption
>> &nbsp; &nbsp;* Nightly spin analysis
>> &nbsp; &nbsp;* Source-level code/diff viewer for  
>> auditing/annotations/linking
>> &nbsp; &nbsp;* Realtime message broker integration into our  
>> existing infrastructure
>> &nbsp; &nbsp;* Realtime widgets to visualize these live data streams
>>
>> luke
>> _______________________________________________
>> infrastructure mailing list
>> infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>>
>
>
>
> --
> Stephen J Smoogen.
> "The core skill of innovators is error recovery, not failure avoidance."
> Randy Nelson, President of Pixar University.
> "Let us be kind, one to another, for most of us are fighting a hard
> battle." -- Ian MacLaren
> --
> websites mailing list
> websites@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/websites
>


----- End message from smooge@xxxxxxxxx -----


-- 
websites mailing list
websites@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/websites


[Index of Archives]     [Fedora Users]     [Linux ARM]     [ARM Kernel]     [Older Fedora Users]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux