"Usage" metrics and analytics. There's at least two kinds of these. One, which components are most used in a running system. Two, which components are rewritten/accessed/opened the most by developers/programmers/people. Why? If a component is used a lot by the running system, but no developer/programmer touched it in a long time, it means it "works", therefore we can focus our efforts elsewhere.
On Sat, Dec 8, 2012 at 11:09 AM, Charlie Derr <[email protected]> wrote: > On 12/08/2012 12:01 PM, David Barbour wrote: > > Just tossing in a few words I'd like to see well supported: > > > > Distribution > > Deployment > > Installation > > Integration > > Upgrade (data/state migration, transition between dependencies, > consistency > > guarantees, deployment of) > > History (cross cuts most things) > > Dependencies, Entanglement > > Version Control > > Merge > > Data persistence (e.g. schema, tables) > > Discussions (e.g. something like talk pages, user pages on wikis) > > Tasks, Priorities, Bug tracker > > > > I'm sure I've missed many. > > > > I'd add attribution (with hopefully a fair degree of granularity). > > ~c > > > > > > On Dec 8, 2012 8:10 AM, "John Carlson" <[email protected]> wrote: > > > >> So I was just designing a generic architecture presentation, and I came > up > >> with 5 different types of views. Are there more? > >> > >> Editor (programmer, designer, scripter) > >> Debugger (programmer) > >> Browser (end user, player, sharing) > >> Configuration (setting property lists) > >> Administration (ACLs, grant, revoke, capabilities, upgrading schema) > >> > >> What are the FoNC thoughts on supporting all these views? What's the > best > >> approach for children? On one of my projects, we combined the Editor, > >> Debugger and Browser into a single view , which we called the workbench > (or > >> recorder), then we added views for various tools we wanted to > incorporate. > >> If we would have had a GUI builder, we probably would have had > >> Configuration. What I don't know how to do is incorporate > Administration, > >> except by providing capabilities to share behavior and structure. How > does > >> the user interface for capabilities appear in FoNC? > >> > >> John > >> _______________________________________________ > >> fonc mailing list > >> [email protected] > >> http://vpri.org/mailman/listinfo/fonc > >> > > > > > > > > _______________________________________________ > > fonc mailing list > > [email protected] > > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
