On 02/03/18 05:58, Stephen Houston wrote: > I've been pondering writing this email for some time now. As others have > mentioned - our community has been trending downwards. Work from Samsung > aside, and those that use E/EFL through Samsung's work -- The developer and > user base has been getting smaller and smaller. That is regular members of > the community contributing work and regular members of the community using > E/EFL as an option for their linux desktops/laptops. The number of > arguments that are now occurring among those of us still left has been > rising. The current state of the project is such that dissenting > opinions/code are not allowed and get reverted or overruled in discussions, > this likely directly related to our structure and our lack of documented > road maps, goals, and plans. > > This project has been around for decades. Many of our developers have > spent blood sweat and tears adding code to this project and working on it. > Many of our developers have poured just as much code into this project as > the next has. The project has become so much more than just one person's > vision or one person's opinion. As it is the project is really not set up > to handle this. There is no clear decision tree. No clear path for what is > and is not accepted. No clear direction of what the goal is to > accomplish. This has been leading to so much animosity, and frankly a > stagnant project that is dwindling instead of growing. Sure plenty of code > gets written, rewritten, or worked on, but the majority of it is not seen > in the product. It is working on rewrites for performance, bug fixes for > corner cases, implementing new apis that are not used anywhere, etc..., > etc..., and all of that is fine and necessary, but other very important > work gets left out. Take Enlightenment from late 2000s - now. A lot of > work has been done. Compositing, Wayland, e_widgets -> Elm, etc..., etc... > But in the last say 10 years... You could pull up versions of Enlightenment > and without a technical sense or from someone following the project, you > would think it is the same... Same menus, same settings, same gadgets, same > shelves, same themes, same look, same interface, etc..., etc... EFL > consistently is worked on and sure is doing really cool new stuff like > Interfaces... but does it matter if no one is even using it? (Samsung > aside). We have 3 or 4 applications that we have always had and there > seems to be very little growth. We have people who have decided to fork > off work or go their own route... see Moksha, Fyne, etc... due to problems > within our community or our vision. This is difficult for a community like > ours to overcome when and if we lose users when we already have few to > begin with. > > I believe it is time that we as a community revisit ourselves and consider > restructuring. Projects can't just be YOLO with no clear laid out > direction or plan. Community based projects can't succeed in an > environment where there is seemingly no project management and discussions > only happen when a feature or change is pushed and one person overrides > it. This project needs to have more project management. Goals need to be > laid out. Road maps need to be developed. Release plans need to be > created and adhered to. This project needs structure, and frankly this > structure needs to come from more than just one person. There needs to be > a team of project managers who determine whether changes, features, or > proposal are accepted, not only one person. There needs to be a team of > project managers determining the direction of the project and developing > road maps for it. This team needs to be represented of our developers, our > corporate interests, and our community user base. Having a team will keep > from personal bias, desires, or egos getting in the way. Once we have some > structure in place, it will become much easier for us to band together to > work towards meeting our goals. > > As it is - It really feels like if we continue on the path we are on, the > future is not bright at all. If we treat this project's goals as whatever > meets the desires or ideas of one or two, that is what it will eventually > become - a project used by one or two. I'm pleading with everyone to put > egos aside, put personal ambitions, personal goals, and related aside and > begin working as a team. The current climate will improve dramatically if > that happens. > > Before you get upset and respond angrily at this email, remember I love > this project and have worked on it for over 15 years and developed > relationships with most of you along the way, and so I am in no way sending > this email with ill intent or to anger or hurt anyone. I'm sending this > email in hopes that we can only improve as we move forward. > > Thanks, > Stephen
I'm going to agree and disagree with a bunch of stuff here, as a starting point, we are an open source project, people should feel free to work on / add whatever they want or think is needed. For example one reason I haven't added any new gadgets in the last 5-6 years (old system) is because for me nothing has been missing. With this in mind, I think that roadmaps can be useful and to a lesser extent maybe someone doing "project management" in a loose definition of looking after the roadmap. However I don't think the Idea of project managers deciding on features / roadmaps is feasible or workable though, it works in a commercial environment because you can then go and tell people to work on X and have it finished by Y. I think a better way of phrasing it / using the roadmap concept in open source is this. You have a roadmap, it starts out as an empty document. Lets say one for E and one for EFL, if someone would like to work on a new feature they'd send a email to the mailing list, it could be discussed so people know its happening and can sort out any design issues so there never should be an excuse to revert a feature thats added later in git unless its really broken. After being sent to the mailing list the feature could be added to the "Roadmap" Either by the Author or "Project Manager" at a Minimum it really just needs a Title, lead developer and list of people working on it, it could also point to a phab ticket with more info and if people had some idea when it will be finished (or if its finished but not in a release yet it could also show that). This sort of thing would help greatly with release planning, for example having not being playing close attention to the commit log of late I have no idea what new features are in for efl 1.21 outside interfaces, if we could clearly see that there are 4-5 other new things ready other then interfaces it would be easy to go well maybe we should do another efl release now although interfaces aren't done, this would have been helpful for efl 1.20. Alongside that it gives a clear picture of what "Needs to be done" in the project, should someone feel that they want to help contribute but don't have there own thing they want to add, they can at least see whats been worked on and get in contact with the main developer to find out how they can help. Similarly we could add a section for feature requests giving a greater list of things people could work on should they be looking for something. So where do project managers sit in this? I don't think people should have to do work they don't want to. That means that not everyone may put there new stuff in the roadmap, so project managers really just become "Roadmap Maintainers" they are people who believe in the importance of a roadmap and keeping it up to date, if they see features added that aren't in the roadmap or know that things like interfaces are being worked on but don't currently sit in the roadmap, A useful enough roadmap can still be basic enough that anyone with some idea of what is happening can update it easily, all it needs to be is a simple wiki page. Hopefully as its created and people view it and see its usefulness they will also see the usefulness in contributing to it. Rather then using the roadmap to say we are going to do this this and that feature, they should be done by time X so we can release at time y, I think it would be more beneficial to use it the other way, ie we can see that features X,Y and Z are close to done they are probably big enough to warrant a release lets work towards stabalising and releasing in the next couple of months. Having said that I think it would be reasonable for efl to go back to 3 monthly cycles once interfaces are done. Thats just my thoughts anyway on a sort of compromise halfway version thats more likely to work in our and other open source projects that may not have as many contributors as others. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
