On Fri, Apr 15, 2011 at 11:17:32AM -0500, Ted Gould wrote: > On Thu, 2011-04-14 at 13:16 -0700, Bryce Harrington wrote: > > On Thu, Apr 14, 2011 at 12:41:22PM -0700, Kees Cook wrote: > > > On Thu, Apr 14, 2011 at 02:17:47PM -0500, Ted Gould wrote: > > I don't think we should do this unless we also have the manpower > > resources identified to bring apps up to meet the standards. There are > > a lot of otherwise good, powerful applications which simply haven't kept > > up with the latest GUI technologies, and it would be shooting ourselves > > in the foot to simply drop them. > > Well, I don't think we'll ever have the manpower to change all of Open > Source for any particular vision. I'd love that, but I think the > expectation is unreasonable.
Yes, I completely agree there. Thus I think the tactic of dropping applications that don't change to meet our requirements would simply be detrimental to our own goals. In a way it's sort of a blackmailing strategy -- do something or else we'll do something to diminish your project. It might work in a few cases, but it's also going to piss others off who may choose to do differently just for orneriness, and there's going to be a huge number of projects that just won't care one way or the other. I think in the end we'd find ourselves in a difficult position of having to either drop a lot of software from the archive that we'd actually prefer keeping, or break with the policies. > > If the goal here is to motivate projects to implement particular > > technologies that we want to see more consistent across applications, > > there are way more effective tactics to employ for that... > > Like? :-) I'm glad you asked. :-) First, understand there are basically four categories of projects we're talking about: a. Finished projects. The program works and is stable. It may or may not be maintained, but new feature work is not going to be done. b. Active, pro-Ubuntu projects. c. Active, but Ubuntu-agnostic projects. d. Failed projects. The code's available but in buggy state, no one is left actively maintaining it. Obviously, some tactics will work great with one type of projects, but fail miserably with the others. With that said, here's a list of suggestions: * Visibility in USC. Like the blackmail approach but we're using a carrot instead of a stick. Apps that don't meet the requirement will still be available via apt, but won't be findable through USC. (Or maybe a checkbox buried deep in a menu allows for non-compliant software.) Or it could be a factor in determining "Preferred" apps. * Barn raising. Like a cross between BugDays and Ubuntu Developer Week, you'd arrange a week where each day you'd have a session to discuss and explain one of the requirements, and encourage community people to engage in implementing that functionality for various applications. You build a list of suggested apps to work on, and let people sign up for one to work on (individually or small teams). Show them how to submit patches to the regular sponsoring process, give some tips or help forwarding the patches upstream. Look at how well received the PaperCuts project has been; here we're using basically the same approach. * Publish a Ubuntu Human Interface Guideline. You'll remember in Inkscape early on we paid a lot of attention to HIG compliance even though we weren't even a GNOME project. Having that guideline available for reference settled a lot of arguments. Make it well written, well thought out, and backed by design and usability experts and testing, and I should think it would sell itself, no need for carrots or sticks at all. * Split the archive. Instead of Main/Universe, you'd have Main/Galaxy/Universe, where Galaxy is the subset of universe that meets the new Ubuntu policies. Universe still exists for those who really need it, but most people would be encouraged to stay within just Galaxy. * Roadmap it. Create a list of all the apps you want to support the set of requirements. Prioritize and organize them into a sequence of steps, easiest/most-important first, and hardest/least-important later. Don't attach any due dates, but imply that achieving one phase per Ubuntu release would be desirable. Then, start from the top implementing the functionality into the first group. Encourage others to hop in and join the effort at whatever point in the roadmap they feel motivated to work on. Let the projects on the roadmap know that they're on it; indeed that alone may be enough motivation for them to do the implementation work themselves rather than wait for someone to do it externally. Well you get the drift, there's probably a lot more ideas along these lines. The basic idea is not to motivate people by making threats of taking something away; instead find something you can easily give as an exchange, or identify a rallying point to gather people to your cause. > > If the goal is to clear out clutter from universe and/or main that we > > have to support, I would think Debian already should have processes for > > this? > > It's less about trying to "clear out" as much as "make better." I > imagine that most projects would have the examples I listed as a goal, > that they'll get to at some point. We'd just be establishing a deadline > or requirement for that. Good luck with that. ;-) Seriously though, surely you remember how much trouble we had in Inkscape with *internal* requirements and deadlines... As I recall it, when external people came to us with external requirements, we were basically like, "Yeah, if anyone feels like working on it maybe..." Setting requirements with deadlines is only *maybe* going to work for type (b) projects, and even there I'd be rather skeptical given that so many people are doing development in their own freetime and have their own priorities they'll tend to first. It's a more corporate oriented tactic that doesn't always fly so well in open source projects. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
