The way of team work with Center release candidate?

[DGDanforth]

Regarding the voting about the issues resolved in the CPC edition.
There are more than 50 issues resolved by now. So it will be a tedious process to
vote about each one separately. In the future this might be an option,
but for keeping up with the backlog I am afraid it is too much overhead.

- Josef

I agree with this. Just jump in and then do bug fixing on the CPC version as they are discovered.

-Doug

[ReneK]

I think it would not be fair to Helmut, who decided to not be part of the center, if we simply took his version and ran with it, claiming it as our own.

No, we do not have to make every change on our own without the wider community, but we need to know and understand each fix and see if it is documented in-source in the way we want, and we should not just cut and paste from different sources (or from one single source).

Also, I think that there should be some coordination process on every release. Something like "Here is the list of all known bugs. Who wants to tackle which issue until when?" and then the center members can answer. The bugs fixed in the next release are those where center members committed themselves to finding a solution and documenting it in the Center way insource.

[Ivan Denisov]

I think it would not be fair to Helmut, who decided to not be part of the center, if we simply took his version and ran with it, claiming it as our own.

No, we do not have to make every change on our own without the wider community, but we need to know and understand each fix and see if it is documented in-source in the way we want, and we should not just cut and paste from different sources (or from one single source).

Also, I think that there should be some coordination process on every release. Something like "Here is the list of all known bugs. Who wants to tackle which issue until when?" and then the center members can answer. The bugs fixed in the next release are those where center members committed themselves to finding a solution and documenting it in the Center way insource.

+1 (this view is very close to my)

[Josef Templ]

I think it would not be fair to Helmut, who decided to not be part of the center, if we simply took his version and ran with it, claiming it as our own.

Why don't we ask Helmut directly?
I don't want to speak for Helmut, but my understanding so far is
that it is absolutely OK for him that the changes go into the center version.

Regarding the OberonCore Version: my understanding is that most if not all
the OberonCore issues are also resolved in the CPC edition.
(The opposite might not be true, though.)
There was a lot of interaction between Helmut and OberonCore in the last half year or so.
Can somebody provide a list of unresolved OberonCore issues?

- Josef

[cfbsoftware]

I think it would not be fair to Helmut, who decided to not be part of the center, if we simply took his version and ran with it, claiming it as our own.

Why don't we ask Helmut directly?

No need to now. He has already made his wishes clear in the BlackBox Mailing list:

The BlackBox 1.7-RC1 CPC Edition is free for using.
If you would like to use it as base for you further development, I will be glad.
If you would like to merge it with your assembly, I will be glad too.

We should certainly not claim it as our own in the same way that he doesn't claim it as his own. He has gone to great lengths to document the changes and attribute each of the modifications to their originators.

- Chris

[Ivan Denisov]

Helmut, is there any documentation of the changes you made in your version? They can help to transform changes into the issues. If no, please, help as to deal with the big work that you have done.

The Center decided to make smoth evolution from 1.6 to 1.7, so we need to make step by step integration of the work you done. Without your help this will be much more difficult.

The benefits of cooperation is the united BlackBox community, which is using the one version of BlackBox. This is very important for components sharing and development.

[Robert]

I am responding to Doug's recent email "We need to do better ...".

I doubt that it is practical, or desirable, to have an individual vote on every proposed change/inclusion into each release.

So ideas ...

We should copy the Wikipedia idea of a two stage process. They have policies (such as "No original research" as they are an encyclopedia, not a technical journal).
These policies are discussed.

Then the articles are also discussed both for their actual content, and whether they comply with the policies.

We should also, over time, develop written policies. We should vote on accepting these policies. One might be "We should aim to prepare a new stable release about every 12 months".

Then for the next release we should have a large table (maybe a Wikipedia page) which we can all edit. It should have a row for each suggested change, and two columns for each centre member.

One column would be technical, and have options like:

- I think this is a good change, and have checked it thoroughly
- I want to see more evidence that it has been adequately checked
- I think it still has technical problems

The other column would be policy, and have options like:

- I think it complies with our policies, and should be included
- I think it does not comply, and should not be included.

When there is a difference of opinion a separate discussion would be started, and usually the proposal would be changed until all the participants in the discussion agree a way forward.
One rare occasions no unanimous agreement would be possible, and those items would go to a full vote.

When the new release is due it would be prepared to include all the topics with (say) >= 3 technical supporters and >= 3 policy supporters and no non-supporters (unless it had been subject to a separate vote.)

With this approach many centre members would not explicitly discuss many topics unless they chose to, but they would vote on accepting the final list to be included in each release. They would also have voted on the policies on which the list was based.

[ReneK]

As we have seen with the usage of unicode characters (I think), Helmut's work is important and good, but we can deliver something better by discussing the issues.

Thus, though I think that every topic Helmut addressed needs to be addressed by the center release, too, we must not simply use his fixes without discussion.

Not everybody has the time or the knowledge/ressources/interest to collaborate on every fix.

So, what if we have a listing of all the problems (and proposed fixes). Each center member then decides which topic he wants to be included in, and then this is the team to discuss the proposal. They decide, and the rest accepts it.

I see no value for me to vote on an issue I am not equipped to discuss, and honestly, I do not think that each one of us is equally interested in, say, compiler fixes.

OTOH, for the next release, I propose to produce the modules for MS Office 2010 Automation. Since those are produced semi-automatically, I do not think that we need to vote on the implementation....

[DGDanforth]

So, what if we have a listing of all the problems (and proposed fixes). Each center member then decides which topic he wants to be included in, and then this is the team to discuss the proposal. They decide, and the rest accepts it.

I like that proposal!
Call it "Issue group".
I think that each issue should have at least 2 members in its group.
If an issue has less than 2 then that issue can not be included in a release.

Anyone else have comments on this proposal by Rene?

[DGDanforth]

Issues list
We now need to post the unsolved list of issues.
Helmut has included that list in one of his emails about his BB1.7 release but
I can no longer find it.

Helmut,
Could you create a new topic "Outstanding Issues" and post your issues there?

We (Center members) can then signup (somehow) for an issue and start work on
it using your code as a base which we can accept or modify.

-Doug