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... > and we now have a clear idea of the initial major work items for this > release. With this in mind, some very small changes have been made to the > proposal workflow on phabricator to improve usability and visibility of > proposals: > > * A 'work proposal' tag has been created. If you want to create a proposal > task, tag it with 'work proposal' and 'efl', and it will show up in the > pending proposals sidebar query. > > * Accepted proposals have been tagged with 'active work proposal' and a > sidebar query now exists for these items. > > > Some FAQs: > > Q: I didn't write a proposal for work that I am planning to do, what > happens now? > A: Create a 'work proposal' ticket as described above. 5 weeks from now, a > second voting session will occur, and any proposals which are not rejected > will become features of the 1.22 release. > > Q: What is a proposal? > A: Documentation is being written about this ( > https://phab.enlightenment.org/T7329). A proposal should include a > description of the work which you are planning to do. If the work is > complex, or the reason for it is non-obvious, explanations should be > provided to justify the work. > > 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 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. 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. > Q: When do I need a proposal? > A: If you are planning to do work which is large or requires a lot of > change, you should create a proposal. This may include things like major > refactoring projects, adding features affecting multiple components, adding > a feature which fundamentally changes how EFL works/runs/builds, or any > other item which may be considered controversial. > > Q: When do I not need a proposal? > A: If you are adding a trivial feature (e.g., a get method for a property) > or fixing bugs, you probably do not need a proposal. If in doubt, create > one anyway in order to avoid conflict. > > Q: What happens to already-submitted patches which implement features? > A: Patches implementing features which were submitted on phabricator prior > to the 1.21 release will not require proposals and can be reviewed/accepted > normally. This is a one-time acceptance to avoid creating more work for > people who had completed projects prior to the current development cycle. > > > If anyone has any other questions, let's talk about them so that we can > avoid any confusion. > > Regards, > Mike > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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
