Ron, I will be brief about this one. I think somebody already kinda answered
about the PMC role in another thread.
For me, and it's a widely shared view at the ASF, the PMC roles should be very
limited. We should, as much as possible, open discussion to the community.
Voting for new committers, PMC member and discussing about vulnerabilities are a few which can't obviously be open, but the others should (I missed
some?).
Despite its name the Project Management Committee is not "managing" the
project, it's more a shepherd.
So don't expect the PMC to lead the project, it's not its role. Everybody can
start something, but then better to be sure you will support this thing...
To start something the best place is this dev ML
You said
>I think that some of the participants underestimate the strength of a well-run open source project in attracting good people and getting great
effort from volunteers.
You're absolutely right, the recent rejuvenation of the project shows it!
Jacques
Le 24/09/2014 17:21, Ron Wheeler a écrit :
Good points.
What I see as missing in the on-going discussion, is an understanding of the
role of leadership in consensus building.
There has been a bit of talk about "forcing" and "enforcement".
The PMC needs to meet regularly to agree on policies and plans that everyone in the PMC thinks is the best way to run the project and produce a high
quality product in which users will be comfortable to invest.
Once the memebers of the PMC and the contributors agree on a plan that involves work, the expectation, in an open source project, is that the team
members will take on the tasks that need to be done.
Clearly, some people will have changes in their ordinary workload that prevents them from living up to their agreed commitment and you have to hope
that they have enough professionalism to help turn over their tasks to others and that others will step up to take on the tasks.
People who routinely fail to do the tasks to which they have committed during
the planning phase will drift down the meritocracy.
Those who step up to perform extra tasks will move up the ladder.
Companies who require the release may also step up to the plate if the PMC
needs additional resources and makes this known.
As many have pointed out, the PMC does not have the traditional management tool of the "Goldern Rule" but this is not a very effective tool in a
world where most of your staff can get a pretty good increase in gold by switching jobs.
The chair of the PMC and the senior "executives" are restricted to concepts like leadership, recognition, mutual respect and the other more
effective tools that good managers use in any company that is successful in software development and is able to retain staff.
I think that some of the participants underestimate the strength of a well-run open source project in attracting good people and getting great
effort from volunteers.
Certainly the recent Bug Crush is an impressive display of people and companies being willing to step up to the plate to complete a well-defined and
well-communicated task.
The PMC needs to be very transparent about decisions that affect the community.
To me, important ones are functionality roadmap changes, release roadmap
changes, resource requirements and the intermediate term product vision.
The PMC should be meeting to discuss important proposed code changes (framework API changes, major functionality, whatever the PMC thinks is
appropriate).
The proponents should present their case in a way that covers the major issues that will affect the PMC and the product such as integration,
features, technology base, maintenance load, etc.
The PMC and the proposing team should agree on a target release with some deadlines which the proposing team must achieve in order to be included in
the target release.
A written policy and process would probably be helpful.
Community involvement in the process needs to be focused on key issues and
marketing issues in general.
This is just a suggestion about how I would handle this
The PMC can do what it wants but it needs to be transparent about the process so people don't waste a lot of time and get pissed off at last minute
rejection of their ideas.
They should know ASAP how the PMC views their idea - great for inclusion into the core functionality, could be official OFBiz extension, is more
suitable as private extension that the PMC will not warranty, bad idea that would not integrate well with OFBiz for business or technical reasons, etc.
The PMC and community should also clearly understand and dispassionately discuss the projected increase in complexity (dev and user), risk of
reduction of reliability, increased cost of on-going maintenance, strength of the team making the proposal for on-going maintenance, delay this
would cause in getting a release delivered, etc.
I hope that these ideas help.
Ron
On 23/09/2014 5:26 PM, Jacques Le Roux wrote:
Hi Ron,
You suggestions are often great, let's see now if the users community if
sufficiently interested to help the OFBiz de team in achieving all this....
Remember that the Apache way is more about flexiliby and lazy consensus[1]... In other words, as volunteers, we must adapt are the daily reality we
all face...
For the sake of OFBiz history, I must say that, not all but at least a good part of the applications at least, has been built in a process of
agglomeration. Contributors (committers or not) work for a client, or their own needs, and decide to give their work to the community. If the
quality is correct and the work is worth it, it's integrated by a committer (with the help of all volunteers). It's not the PMC nor any other group
which really decides of what should be there or not. It's more individual decisions, filtered of course by everybody for the benefit of the
community. Anyone can raise a hand and say his word, that's how it works actually, and it seems you are already aware of that :)
I don't say we can't improve, but I doubt that more rules (enforced? how?)
would help.
For instance, sometimes I even wonder about this page
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
Even if I still think it's helpful, is it not a bit frightening for a new
comers (it's just an exampled not really a question ;)
More answers inline...
Jacques
[1] http://www.apache.org/foundation/voting.html#LazyConsensus
Le 23/09/2014 07:40, Ron Wheeler a écrit :
I think that having a discussion about the policy followed by regular (annual or semi-annual) discussions on the roadmap with the PMC and the user
community will have a couple of effects
- fewer surprises caused by users showing up at the last minute with requests to extend the EOL or EOS (End-Of-Sales->no longer on the download
page and no longer recommended for new uers) dates.
- more commitment from the user community to help with maintenance or to
support sub-projects financially or with resources.
I have not been here long enough to know how the PMC decides on what features will be in a new release or how investigation of new sub-projects
such as the Workflow project, get accepted as "good" ideas or rejected as "out-of-scope" or insufficiently supported by the community.
Is there a formal procedure that I would have to follow to get my favorite
feature included in 14.XX??
Nope as barely explained above
How does the PMC close off the 14.XX spec?
When it's ready :D By lazy consensus (anybody can raises a hand, but he must be
in tune with what happens)
I assume that there is a process that involves the PMS and contributors who will be providing the resources and the user-community that determines
the pluses and minuses of the proposed change.
Nope, we try to avoid "'paper work" as much as possible
What are the current new features that are being considered for the 2014.XX
feature freeze?
Is this discussion documented somewhere?
Nope, but Jira can give you more than a hint
https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
This the way we are recently going and it's a huge progress in comparison of
what we had before (almost nothing and despite you see: OFBiz is there)
The people doing the investigation of the Workflow engine presumably need to know when they have to get their proposal finished to make it into
the 2014 feature freeze.
Obviously, this does not depend on us (OFBiz dev team) but them (to be ready
and ask to wait if necessary)
Are their guidelines about how the form and content of this proposal (features, dependent software , integration issues, resources required,
estimated time to deliver)?
Nope, would you suggest something?
Jacques
Ron
On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
<<the problem is not everybody is aware of bug fixes backported or not. The official download page http://ofbiz.apache.org/download.html, says
that we
stabilize releases with bug fixes. It's not quite clear if we are backporting all or
only some bug fixes.>>
A more formal rule would be:
* commits to the trunk from Jira tickets of type Bugs can and *should* be
backported to all the active releases
* commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be
backported to a specific active release
<<I think we should make that clear and expose a way to users for them to more
"easily" maintain the releases they use.>>
+1 see below
As suggested Ron we could also define our own or refer to
http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download
page where we already mention a tentative end of life; for example now we have:
• April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
But when we specify an end of life, we should also make clear a few things:
* this is a community goal, and the help from the community is required to meet
the goal (i.e. it is not guaranteed)
* the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release
branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low
interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
Now we need to think "technical" and automatize as possible with Jira
In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the
information will be more accurate with new releases).
The idea is to run a query on Jira with the following constraints:
project = OFBiz
type = Bug
status = not resolved
version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g.
"Release 12.04.05")
The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and
outstanding.
For them we will need help from the community (committers and non committers)
to fix the bugs or backport existing fixes.
In the download page, we could add two links (to Jira) next to each available
release:
1) known bugs (links to the above report)
2) release notes (link to the release notes available now)
One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version
affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add
"12.04.06" to affected version).
What I have read so far from Jacopo seems a good start to me
Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information
when I started the version refactoring in Jira, and this conversation is helping to refine some points.
Jacopo
