...
| Warning |
|---|
in process of being tidied up |
Comments about release proposal:
- the possibility of being able to introduce new functionality to 2.7 should be explicitly stated
- Staffing of release team - anthony and pete identified, and then somebody unknown. some clarification of their responsibilities. explicitly calling for one or two more people.
- a 2.8 branch manager should be identified early
- pragmatism ... people willing to be branch manager depends on deployment schedules, 2.7 schedule may be in jeopardy if there are no schools willing to adopt it.
...
- Whether or not one deploys can be influenced by feature set, and so 2.7 may introduce risks here.
- brings up the old question of release philosophy
...
- : time-based
...
- v. feature-based, etc.
- uncomfortable with
...
- suggestion of PC's role in targeting particular releases, shouldn't set hard boundaries
...
- is there a pragmatic benefit to southern hemisphere sites?
...
- UCT in particular: would favor independent project releases
...
- instead. A forums release would be more useful than a full 2.7 as currently described.
- What are good prospects for projects ready to work with us, and targeting 2.x?
- Chuck with LTI, Kirk Alexander with
...
- Gradebook2, Assignments2 at IU, Nuno with SiteStats, perhaps others
- LTI a good first prospect in some ways, but won't present a
...
- thorough workout of the process because it's fairly narrow. Still, may present some issues that would be good to work through (such as cross-institutional support).
...
- Whatever we start with, wouldn't want it to
...
- be something that
...
- might tend toward rejection
...
- It's not really rejection, it's more a process of
...
- identifying what more is needed, and helping people to get there. It's valuable to raise these questions in a solvable form. Spur to doing work in incubation
...
- Would be good to review code in light of our ability to support it; eg LTI touches on portal - who's working on that, who can, and what would that mean for maintenance expectations?
- Would something like LTI allow us to fast-
...
- forward the development stages in a collapsed timeframe?
- Need to get projects to self-document, with standardized documentation to show that it's gone through the steps
...
- .
...
- Wouldn't want to have to say
...
- "Do these steps," then check them off, then
...
- come back with more steps and keep ratcheting things up ... want to lay things out clearly ahead of time
...
- Whether or not there's a maintenance team ... might influence these decisions [aside: Anthony's working on a proposal for this]
...
What Product Development Means for tool 'stealthing' convention:
- in provisional criteria there was this notion of stealthing. Are we dropping that distinction?
- it's a valuable option, but I would focus on the goals and see if they could be achieved otherwise - if it could be a contrib project and applied
...
- easily
...
- to a main distribution, then that might meet the same need. But not everything may be easily packaged in this way. It's mainly a question of distribution mechanism.
...
- Leaving things in contrib has led to an unhelpful confusion over status of contrib projects
...
- . And yet if a tool is in a release
...
- in an
...
- optional way there is a similar level of confusion.
- Stealthed provisional tools feels like a workaround solution, and not something that should be embedded by default. We should test if we can get rid of it. Should be clear that we hope and plan to get rid of it when feasible.
...
Basic Documentation for entering Incubation: (see Incubation Documentation)
- Would like to see clearer description of process: make it public enough that people can see what's happening, how to get involved and how you see the process to be managed.
...
- For example, it seems the Foundation already committing resources to Sakai 3, need to look meaningfully at K2, eg, ... documenting clearly about what's going on
...
- Would it be asking too much to ask people to list rough timeline?
...
- Arriving at a credible timeline may be what they're trying to get into incubation for in the first place
...
- : to recruit resource, flesh out a project plan
What Happens in Incubation:
- Useful to set some sort of deadline on incubation period.
...
- Concerned about corpses of incubated projects that never go anywhere, need somehow to keep that from going on indefinitely
...
- One strategy: just a clear statement of how it will get out of incubation
...
- . Helps the question of timeline.
- That can help, but then people
...
- might be pulled off the project, etc. starts to create clutter that is confusing
...
- Clutter as such not a big worry. Helpful to see clutter that has good information in it. Worried more about zombie projects that have nothing going on.
- Right, the issue is misinformation; a project in incubation may be dead, whereas we want incubation to be a sign of community activity
- Apache has "the attic" as a way to shelve things that go dormant
- It may be part of the PC role to review and determine whether a project should continue in incubation
- This triggers a thought about apache
...
- . They have an interesting model of getting regular status reports
...
- . Clay might give an update, could be helpful to identify where projects are running into trouble.
...
- Could be very brief report, a paragraph or so
...
- needs to be more frequent than annually, and a lack of reports is a good indicator
...
- difference btw 2 and 3?
- for 2 a narrower set of issues to be canvassed, 3 broader and more complex
- would be sad to deal with them in isolation
- one of the characteristics we ask projects to demonstrate is how they integrate, how does it affect other tools
- let's separate out a couple pieces; separate out interdependencies from whether two tools need to come out in same release. need documentation on service level to demonstrate interoperation. separate hard documentation from hard acceptance criteria. need to document migration plan as well (eg from 2 or 3) and we can advise how significant that will be. keep it simple - need to say something about having a migration plan
- nagging desire to see us document requirements, and want to get drafts going for further stages, and see those take shape.
- Max, Nate and Eli ready to help edit results of discussion.
- got a good starting point. even if only see preliminary thinking, something for the community to begin to reckon against
- seems like this is a decent time, but must be inconvenient for Stephen and John. Stephen: ok if it's not too frequent, like once a month or something. easier to plan for regular mtg. conclusion: bi-weekly slot allocation that we wouldn't always use. If an agenda doesn't come together, Clay will coordinate it being called off.
...