First off - There were a lot of emails about the proposal process with instructions on how it works - as well as phab ticket and slowvote with instructions for how it works there as well. From Raster's email it seems he still didn't read the instructions because he still voted thinking he was voting for "the least bad option", when in actuality not voting meant approval. This isn't a bureaucracy of choosing what can be worked on. All you had to do was put forth proposals of what you wanted to work on (and you still can), and the proposals are automatically in the "Accepted" category with no bureaucracy involved. Thus the only purpose for the vote being to make sure that the rest of the community doesn't have a huge problem with any of the work that would move it to "Unaccepted" (thus you voted and commented if you did). It would take a lot to get a proposal unaccepted, obviously. All proposals were accepted - It wasn't a choose a proposal vote ... It was "this is what has been proposed, and of course we will accept all proposals unless enough of the community finds a proposal disgusting enough to vote against it or say no".
Second - Raster, if you remember we had IRC meetings ran by you where the community got really involved and we discussed and voted on some key issues. You agreed to handle the release process in place of Stefan since he was going out of town. Then you just kind of disappeared and there was no involvement from you so, all of the sudden, we had to pick up the slack on the release process and do what we could. What we found was a process that really worked - Triaging phab tickets appropriately using tags, code review being handle by all, both submitting code for review and reviewing/landing, triaging feature tickets for future releases as to not obscure the work needing to be done for 1.21 release. We did a lot of work in a short amount of time to really improve the release process and work with what he had. From our experience this worked so well that we expounded on that and set forth a plan for the 1.22 release that included this proposal process. >From my perspective - and the perspective of a lot of people involved - the recent structure and process of how we are handling the code base, releases, features, bugs, etc..., has been wildly successful indeed. I encourage you to look at code review and see just how many patches have been submitted and accepted and how well that process has gone. I encourage you to look at how phab was triaged to provide a clear goal that we were able to achieve in a short time to release 1.21. I feel confident that expounding on this process we used to get the release out and using it for the entire life cycle of 1.22 development, it will only become even more successful. If you would like to offer "big pushback" or you "seriously dislike" where things are going - I encourage you to try to understand it first - which I'm sure you did from the way you misunderstood the proposal process. I hope we can talk about this all amicably and come to an agreement going forward. On Tue, Aug 21, 2018 at 10:25 AM Christophe Sadoine <[email protected]> wrote: > On Tue, 21 Aug 2018 at 09:17, Carsten Haitzler <[email protected]> > wrote: > > > > On Mon, 20 Aug 2018 08:15:48 -0400 Mike Blumenkrantz > > <[email protected]> said: > > > > > Hello, > > > > > > We've just completed our first round of voting ( > > > https://phab.enlightenment.org/T7283). The process was a success > overall, > > > > what on earth.... a success overall? how can you claim this? 2 polls. 1 > had one > > vote, one had 2 votes. in total 3 votes. they don't allow multiple > choices. the > > voting against was confusing to 50% of the people voting... and tbh i > voted > > only for the lease bad option because i disliked them all... > > I agree the voting was a bit weird. > And I think there should only be a vote against a proposal if a > consensus cannot be reached. > People could just comment on the proposal task there if they are against > it. > I only see a need for voting if one wants to know what other > developers would like to have the most for the next release. > > > > Q: Why proposals? > > > A: Previously, EFL releases were like a giant pile of unrelated and > > > uncoordinated work. There was no oversight and nobody knew what anyone > else > > > was doing. This methodology provides solutions to these issues and > allows > > > for a framework within which contributors can work cooperatively on > > > features for each release. > > > > yet the community was happy and functioned. we got along like friends. > had our > > arguments and spats but functioned. > > I think that is where most people would argue that it is/was not > functioning. > Maybe it was before, but it looks like it isn't anymore... > > > i for one will happily approve any patches/work that is of value and has > been > > done well that is brought to my attention. proposal or not (if it's a > patch > > submitted). if someone wanted to add something they needed or wanted and > it was > > not proposed - more power to them. they are enjoying themselves doing > what they > > wanted. > > if someone wants to add something that was not proposed, it is fine! > Just communicate about it... they can say "hey I am working on this, > what do you think" that is just more communication right? I think this > is what proposals are for. > But like I said before I don't see why there should be a voting > session against the proposals. There should be good reasons to be > against a proposal first. voting seems too arbitrary. > > > a todo list for people to pick from if they are short on ideas or see > things > > there they'd prefer to work on is what is useful. this bureaucracy is > not. i am > > seriously disliking where you want to push things and consider this a > big push > > back. > > I think it is more or less what we agreed before in irc meetings, > isn't it? maybe I've missed some. > If you have a big feature that will change efl it seems normal to have > a task (proposal) to discuss about it. (and small features do not need > proposals) > For example if there had been a proposal for the gadgets you could > have said from the start you were against it (maybe you did and I > missed it) instead of when it landed. > Because they did what you described exactly, they worked on something > they wanted and merged it. > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
