Dear Rene
I hope that such experienced manager in our family will help with managing the energy of the team. If the manager do not know that some resources (people, knowledge and time) exists, nothing to managed with. I made you an administrator of Redmine some time ago. If you are software manager you knows the strong sides of this system and can help to make right decisions. Do not shame to teach, but do not suppress the activity. If it is for free that does not mean that it is chip.
If you give a reason to start the web-site from the scratch, to make new initial repository we can make everything that is needed to achieve better result. If no ideas we will make our work how we can with involved people. We do not want to see how our everyday tools dies in a hands of slowpokes.
Maybe you can give a breath comment about the branches system we a discussing for new development?
Roman
http://forum.oberoncore.ru/viewtopic.php?f=114&t=4450#p81640
Ivan
http://forum.oberoncore.ru/viewtopic.php?f=114&t=4450&start=20#p81660
The mailing list is bad idea to continue discussion, no chance even to send a picture.
I suggest the mailing list discussion to be continued here:
http://forum.oberoncore.ru/viewtopic.php?f=114&t=4454
I already had copy one of your first letter here three weeks ago:
http://forum.oberoncore.ru/viewtopic.php?f=1&t=4407#p81263
Can you point in new topic the main suggestions?
Regards, Ivan
2013/8/21 Rene A. Krywult <rene.krywult{([at]})nowhere.xy
Well, Ivan, I dont' know. Language is an issue here, definitely, because I often have to guess what you are saying, and even more often, what you really mean. English is not your first language, and it is not mine either. So, I hope that in what I write below, I do understand what you are trying to say and not bark up the wrong tree. If so, I apologize right now :).
From what I understand, you say that we should do first and talk later. And you claim that this probably has to do with age, too.
And you are right: As a child, I believed that analysing, planning and talking was for sissies, too. I had to make mistakes, have high goals *not* achieved, see software projects I had my heart set on crumble because I didn't do the necessary work of analysing and planning before starting to code. But this taught me that anything worth doing is worth doing it right! And to do anything in IT without analysing first is a sure recipe for shattered dreams. If you are not old enough to understand this, Ivan, then good luck with sore knees and broken bones, metaphorically speaking. You'd better listen to wisened old men, if you want to keep your health.
When Omi first made BB OpenSource, the community was glad - but nothing happened. A few years later, I tried to convince the community that we should stop waiting for Omi to fix BB, but start doing it ourselves. I read articles about OpenSource projects and what makes the difference between failure and success, and I sent a few of them to the list. Nothing happened. Why? Because Omi was still there to do the work. So the community of BB using developers didn't need to become a community of BB developing developers.
Now Omi has taken itself out of the equation. They will not be responsible for further developments. A bold move! A necessary move! Now it is up to us to either live up to the task or let BB rest in relative obscurity.
For me, this is like a hike in the montains. I buy equipment and a map, I plan, I prepare, I go, I succeed. If you want to run off without a map and without preparation, fine. But don't you think you'll get lost and exhausted without ever coming to anything?
I'm not someone with great knowledge of machine code, compilers, low level programming and such. I am, though, a project manager and a software developer. That's my bread job for the last 20 years. I know something about what makes the difference between a failed project and a successful one. I know something about RAD and it's strenghts, I know something about SCRUM.
I'm also a networker and community builder, though not in IT. I have experience in religious and in academic communities, I'm also involved with the Red Cross. In all those cases I work with volunteers and as a volunteer. I know how to build a community, and how to keep it focussed and working.
If you think that youthful warhorseship is the way to go in an OpenSource community building effort, have fun. I'll aplaud you for your enthusiasm, and commiserate with you for your shattered dreams.
Rene
Gesendet: Mittwoch, 21. August 2013 um 14:26 Uhr
Von: "Ivan Denisov" <d.ivan.krsk{([at]})nowhere.xy
An: BLACKBOX{([at]})nowhere.xy
Betreff: Re: [BLACKBOX] Aw: Re: [BLACKBOX] Re: [BLACKBOX] [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support
Dear Rene and OberonComunity
This message includes a lot of criticism, but should not be considered as aggressive or anger. I agree with Rene that now is the stage of trial, maybe not because of the cultural difference but the age difference you looks at my "trial" as a final decision. For young is more interesting to trial work then trial talk, because that give a chance to learn more. Also, if nothing to do and show, there are nothing to discuss. I respect everybody for the professionalism and work you are doing. This is dialog you ask for and it will try to explain why I think we should take a look more on a technological part of Community Future Communication.
Certainly the expert work is important, but the "center" without hands and ideas will be a mouldering stump. If somebody take roles called by Rene it is not sufficiently to be the center. As Rene right mention, community should "accept the services and role". I think that the key word here is "services". Oberoncore provide the best service for forum and documentation of bugs. Applause! But the other sides not allowing them to be such "center" them will be touched bellow.
The next scenario suggested by Rene is simply "community", and agree with OberonCore that it is the most probable scenario. But do not agree that BlackBox Component Builder 2.0 should not see the light some time in the future. The community also can make decisions and maintain the versions.
The community of BlackBox can unite three things: 1. Style (minimalism, goes from the N.Wirth & A.Einstein slogan). 2. Technological goal (already wilted and does not bloom yet) 3. The platform (the place to solve your working problems).
The minimalism for work today possible but becoming dangerous and not every user of blackbox enjoy this. That is why the first role for community holding should play the platform. In includes development and distribution part. There was two centers for that stuff before: 1. the H. Zinn collection of components and 2. OberonCore collection. All other stuff was decentralized. As a user and developer I was not suttisfied from both. Their editorial systems makes me fill fear. Also the usage without bug tracking, users comment, ratings automated version control systems was not efficient and I am sure it had decelerated the improvement of components blocking dialog of developer and user.
Today for the development we need Issues tracking system and modern code version system friendly with Component Pascal.
Today for the distribution we need the same automated platform for components as Lunchpad for Ubuntu developers, for Apple Store for Apple developers, for PlayMarket for Android developers.
That two services can make community unite and grow. That is why as a patriot of Oberon language family I do that I do make this services works. All other is conversation "who will be the mouldering stump?". I do not want any "center" decide is my documentation written good or bad, or is my component good to distribute enough. Let the users decide, mark me, give a feedback. That is my idea. Make it modern BUT SIMPLE. Not Mailing list or words blowing forum BUT GIT+REDMINE+CHAT, not static web-sites BUT Kindly Automated Component Store. Not a conference once 4 years but weekly!!! Oberon Google Hangouts.
Technical and organization solutions for this challenges are not on a plate and need to be checked from existent and some are developed from the scratch. The Redmine was one of such check suggested on forum.obeoncore.ru for the development and this check I done and invite you to test it well.
Everything revolves. Robert C. had already gave a feedback of using "git clone" and the issue about zipped archive with BlackBox. Ilya Ermakov had already gave an solution how to fix this server slow start Issue. Oleg N. Cher and Roman Miro have been started pushing Bug Issues and fixing them. I have merged OberonCore, H.Zinn, Maliya, Louwe, M.Frei fixes to master branch. Peter Kushnir working on how to integrate odcTOutf8 converter to Mercurial for have choice between developing system. Helmut Zinn integrates all known fixes to maintain his experted version, we includes all of them in redmine for sure. Boris Rumshin and Eugeny Temirgaleev make great work on forum to make it more friendly for non Russian language users, and I am sure they will maintain new version of their assembly too.
We do know what are doing in Oberon Microsystems AG. Is there is a hope that our activity not make them change their opinion about FreeBSD license? :)
Regards Ivan
2013/8/21 Rene A. Krywult <rene.krywult{([at]})nowhere.xy
Great! I agree. Technical issues, both concerning hosting platform and future development need to wait until there is a "center".
I propose the basic functions I believe the "center" should have:
1) Publication of a stable version of BB Framework
This includes adaptions to future versions of the OS, bug gathering and fixing, testing, documentation, making sure that all changes are "by the book". This does not mean that only the "center" may provide bug fixes, but only the "center" decides, which bug fixes actually make it into the next stable version.
2) Planning and coordination of internationalization
3) Planning and coordination of ports to other OS/platforms
4) Web Marketing of BB
5) Communication between members of the "center"
6) Communication between the "center" and the BB community as a whole
7) Facilitating a central and international communication platform for the community
8) Assignment of Package names
10) Providing a centralized and unified repository of packages (this includes: making sure that those packages are in accordance with guidelines concerning documentation and programming guidelines)
Are we all agreed on these functions? Should any be dropped? Should any be added? After agreeing on the functions, we probably want to document this in a whitepaper.
I propose that after we are agreed on the functions, BB developers need to decide if they want to be part of the center or merely part of the community. And those who want to be "center" need to detail, what skills they have to futher those functions. After that, a charter (what is our vision, our mission, our methods, our rules) of the "center" (and a better name!) should be defined.
Since everybody who is currently BB community would be able to decide if he wants to be part of the "center" or rather simply stay "community", this would be a defacto vote - assuming that those who do not want to be "center" accept the services and role of the "center".
After this process, it would also be prudent to have Omi aid the "center" in making official that the "center" is now the elected successor. Thus, we would be both assigned by Omi AND elected by the community, giving us the best head start to be a joined community service.
Of course, this is just a starting basis for discussion, not a proposal or declaration. Feel free to add, discard or throw it away ;-).
Rene
Gesendet: Mittwoch, 21. August 2013 um 10:06 Uhr
Von: OberonCore <oberoncore{([at]})nowhere.xy
An: BLACKBOX{([at]})nowhere.xy
Betreff: Re: [BLACKBOX] Aw: Re: [BLACKBOX] [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support
Dear Rene,
We agree what "single center of responsibility for BB would have the right to create a version in the future that is not fully downward compatible to 1.6, if that would be necessary." and so on, if it is defined as mentioned above: "Such centre may be assigned as the successor of BlackBox Support Oberon microsystems AG by acknowledgment. Or shall be elected by Community."
But again, there is no point to discuss these technical details while the center is hypothetical.
Best regards,
OberonCore team.
19.08.2013, 00:25, "Rene A. Krywult" <rene.krywult{([at]})nowhere.xy
Dear OberonCore team,
OK, I do not know when you started reading the BB mailing list. But one of my first posts to this topic was about a single center of responsibility, and some on this list have shown their support for this idea. So, on your point 1 we seem to agree.
Concerning your second question, I guess this is a problem in translation only. If a framework is ported, it is, of course, not just a reuse of a name, but a real port. The idea, IMHO, would be that you take a package from BB-Win7 and then recompile it on BB-Linux and BB-Apple OS and BB-JVM without any changes necessary. Would downward compatibility to BB1.6-rc6 be maintained? Surely for HBBF1.7, but for HBBF2.0? Who knows! As you will well remember, BB1.6 is not downward compatible to BB1.2! Omi made the decision that the planned changes were more important than full downward compatibility, and it was well in Omi's rights to do so. Likewise, the Hypothetical single center of responsibility for BB would have the right to create a version in the future that is not fully downward compatible to 1.6, if that would be necessary.
I think it is great that you do a Russian documentation for 1.6, and you probably already have a Russian UI for 1.6. Obviously, a German version, an Italian or French version are not in your scope. The single center of responsibility needs to supervise this task for all languages we have team members for. Also, this could mean that CpcLanguage - or something like it! - becomes part of the HBBF, because without (something like) it, localization could not be easily done in one version.
So, basically I'm saying that the new BB development team needs to call the shots. We need that body, and we need it soon.
Rene
Gesendet: Sonntag, 18. August 2013 um 21:47 Uhr
Von: OberonCore <oberoncore{([at]})nowhere.xy
An: BLACKBOX{([at]})nowhere.xy
Betreff: Re: [BLACKBOX] Aw: [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support
Dear Rene,
> if I understand your official position correctly, you do not concern yourselves with
> *) internalization of the basic BB framework
> *) adaption of the basic BB framework to newer versions of Windows
> *) porting of the basic BB framework to other platforms, like Linux, Apple OS and JVM
> *) adaption of the basic BB framework to better fit the state of the art
> In short, OberonCore does not see a need for a unified and central BB Framework 1.7.
> Is this correct?
1) United centre of responsibility for "unified and central BB Framework" is a precondition. There is no point in discussion about "unified and central BB Framework" without it.
Such centre may be assigned as the successor of BlackBox Support Oberon microsystems AG by acknowledgment. Or shall be elected by Community.
2) We are open to any development and it's our main activity (for example: support of BlackBox Russian documentation for BB 1.6 (
http://oberoncore.ru/projects/bb-docu-ru); BB1.6-rc6 Linux Console (
http://oberoncore.ru/projects/bb16lin-console) <
http://oberoncore.ru/projects/bb16lin-console> ). Hypothetic "basic BB framework" (HBBBF) ported to newer Windows versions, Linux, Apple OS & so on
Is HBBBF compatible with standard BB? Or it inherit it's name only? Who can answer this question now?
There is the concrete public assembly OberonCore BlackBox assembly on the other side. It's based on BlackBox Component Builder 1.6-rc6 (for Windows (XP, 32bit,
)) for now. And it's main development rule is "Primum non nocere".
Best regards,
OberonCore team.
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Wed Aug 21 2013 - 16:27:12 UTC