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
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102